Message-Id: <9302032037.AA11434@Athena.MIT.EDU>
Date: Wed, 3 Feb 93 15:37:45 EST
From: Toshiharu Harada <harada@ceci.mit.edu>
To: jud@ceci.mit.edu, pbailey@ceci.mit.edu, aybee@ceci.mit.edu
Cc: sigmund@nora.hd.uib.no, lynne@Athena.MIT.EDU
Subject: yesterday's meeting

Now I'm reviewing our yesterday's meeting and am trying to find
out what are the points we really have to discuss.  This mail
is not the minute, but summary of what I thought.

---

In the scheme I proposed, ADL (control engine) is loosely coupled with
media classes in C++.  From media class's point of view:

	[ in media classes ]
	clip = new MDclip(QUALIFIED_ENGINE_TYPE, char *arg_for_engine);
	...

and I envisioned corresponding description appears in ADL something like:

	[ in ADL ]
	{ // please ignore the details...
		...
		clip := 'Still, 'ENGINE_GALATEA, "ozone:0, 234";
		...

		clip.play();
	}

the advantage of this scheme (if exists) is:

	o clip's definition can be easily changed without disturbing
	  other parts of ADL description
	o the communication between control engine and C++ media classes
	  is loosely coupled (just passing "strings"), therefore
	  new engine type can be added in media classes without
	  requiring drastic changes in other AM2 source code.

The ADL example shown above caused a lot of arguments:

	o those device-dependent specification should be hidden in ADL
	  (by Jud, Phil, Adam)
	o in ADL level, description should be made in terms of
	  "qualified media types", "volume" and "media address".
	  (by Jud mainly)

So, here are issues.

Issue: "how should media-specific description look in ADL (with example)" and
Issue: "how those description can be linked to their implementations"
	(discussion will not make sense without mentioning to the latter)

If AM2 employs concepts of "volume" and "media address" which
are implementation-independent, how and where should they
interpreted to "real" volume and address (frame ID etc.), or
where can I find the real specification?  Can that be implemented
without introducing special semantics in ADL (in my model,
ADL doesn't need them)? I'd like to know answers to those questions.

Another argument done with my scheme was:

	o shifting to device-oriented media types from
	  six abstract media types proposed in my memo.
	  for instance, "VideoStill" instead of "Still".

I tried, but couldn't really understand the advantage of introducing
a type like "VideoStill" in the meeting. (Could someone explain me?)
The reason I put just six abstract media types in my memo
was I thought it would be ideal for application writers to
think media-specific information in terms of only the information
a clip present (do they want to know where a graphics come from?).

Finally, Jud raised a set of possible problems that can summerized as:

	o how should AM2 act when mounted disks are changed (or
	  rerouting gets necessary)

I didn't answer them in the meeting because I had no idea
what kinds of answers were appropriate to those questions.
Doubtlessly there can be cases where AM2 can't help such as
sudden replacement of a disk.  For those cases I think
what we can do best is to help AM2 from sudden death.
In my memo, I was thinking about monitoring the status of
implementation (software) such as mounted disks etc. in what I wrote
as "C++ wrapper" class.  Then we can at least detect a media clip is
not connected with proper device anymore and can return error in ADL.
Is this not sufficient?

I don't deny the importance of discussing those problems at all,
but it seems to me the priority is not as high as:

	o how media description should look in ADL?
	o how can it be bound with implementation (like galatea) or
	  raw device (laserdisk)?
	o what functionality has to be buit-in control object
	  to make all things work?

Well, this is not all but close to it. (Sorry I'm not organized again)

During the meeting I had been feeling that my point of view was
somehow different from yours, and I still don't know why.  It made me
frustrated and probably made you so.  I'm sorry for that.  But please,
I'm not sticking to my scheme (Jud said he was easy so am I), nor
rejecting new idea meaninglessly, but I just want to make a good
design for AM2 media support as you do.  I really appreciate your
cooperation and am kind of like these meeting.


					--- Toshi