Message-Id: <9302041710.AA10618@Athena.MIT.EDU>
Date: Thu, 4 Feb 93 12:10:22 EST
From: Toshiharu Harada <harada@ceci.mit.edu>
To: Judson Harward <jud@ceci.mit.edu>
Cc: aybee@Athena.MIT.EDU, lynne@Athena.MIT.EDU, pbailey@ceci.MIT.EDU,
        schluss@Athena.MIT.EDU, sigmund@nora.hd.uib.no
Subject: dumping my brain

Jud,

thank you for responding me.

Message from "Judson Harward" on February. 03:
> 	First, what do we mean by "media-specific description"?  We could mean
> at least two things by that:
> 
> 	1) The arguments to a media clip constructor
> 	2) The description of media as provided to a content object

The meaning of "media-specific description" depends on the context
it is used.  In AM2 application programmer's perspective, what
you listed above seems to me appropriate, but more genericly
I think it can be expressed something like "all the information that
is needed to specify media-specific information such as
videoclip, graphics".  For instance, to display a still from
a laserdisc, we had to specify:

	(1) volume name of a disc
	(2) frame number

Please note that one thing is missing here. That is a galatea
package.  In AM1, we didn't explicitly specify the name of it
because it was the only available mechanism that can be used
to retrieve the information (still, videoclip) from a laserdisc.
It is Galatea package that can interpret the meaning of "volume name"
and "frame number".

If AM1 had two or more mechanism (independent package) that can be
used to retrieve information from laserdisc, we couldn't not assume
those two are as solid information as they were in actual AM1.
I believe, in that case we definitely have to specify which
mechanism to be used and can have no concrete assumption for its
argument because argument should be mechanism-oriented.
(it is quite likely any package would support frame number, though)

So I think generic categorization for "media-specific" information
should be something like:

	(1) name of the package (ex. galatea/MediaServer/QuickTime/WhoKnows?)
	(2) anonymous (depends on the package)

Let me summarize my points:

(1) we should not put any assumptions for what kinds of arguments
    will be necessary for a device (CD, laserdisc)

	I can easily imagine software package that doesn't understand
	"volume name".

(2) generic media-specific information can be expressed as
    a combination of "package" and "its arguments".  We should
    not give "arguments" any meaning, because it is the responciblity
    of the package.

> Hopefully, these two are related.  In the ViewerModule example, we suggested
> that a static list of media descriptions for a content object might look
> like the following:
> 	//		      key         media type	addr     volume
> 	content.list := {
> 			  { "myDog", 'analogVideoStill, 1234, 'HomeVideos },
> 			  { "myCat", 'analogVideoStill, 1234, 'HomeVideos }
> 			};
> 
> The media type here is not an abstract media type, but what Phil was calling
> "a fully qualified media type".  We felt it was necessary because if you had
> an analog videodisc played and a photo CD unit both connected to the system and
> you specified the media type as MDgraphics, how would the system know whether
> you meant the photo CD of the videodisc.  I think you would respond, via the
> engine_id.  The problem we have with that is that the engine_id is platform
> specific while 'analogVideoStill is not.  How should this be translated into
> arguments to a media clip constructor?  You tell me.

Let me first show you my version of ADL example here.

content.list := {
  { myDog := clip('GRAPHICS, 'ENGINE_GALATEA, "HomeVideos, 1234") },
  { myCat := clip('GRAPHICS, 'ENGINE_QUICKTIME, "I don't know") }
};
			
Now I answer to you question.

> specific while 'analogVideoStill is not.  How should this be translated into
> arguments to a media clip constructor?  You tell me.

ENGINE_GALATEA in above example is not a galatea package itself, but
a wrapper C++ class (object).  There's no difficulty in inventing
syntax that is to inform the wrapper object to determine 
what application writer wants is Still or VideoClip and the
wrapper object can call appropriate Galatea function.

content.list := {
  { myDog := clip('GRAPHICS, 'ENGINE_GALATEA, "HomeVideos, 1234") },
  { myDoc := clip('VIDEO, 'ENGINE_GALATEA, "HomeVideos, 1234-2455, 30") },

Next, you wrote that "engine_id is a platform specific while
'analogVideoStill' is not".  I couldn't understand it.

I'm envisioning 'engine_id' for a package will be assigned uniquely
across all different platforms for AM2.  For instance, if we assign
ENGINE_QUICKTIME to 100 (or "AQT") it will be 100 ("AQT") in
Sun, PC and Mac.  And as long as that engine_type is available
I assume the argument can be shared with all platforms.

On the other hand, your 'analogVideoStill' can be used
across different platforms too, but what it actually means
(or combined) is anonymous, which means somebody has to take care
of it while in my scheme it's totally given to the most appropriate
component, package.

I think your idea is equivalent to introducing 'GalateaStill,
'QuickTimeStill', 'MediaServerStill.  Your 'analogVideoStill
is implementation dependent all right, but actually it's just a label
and will be interpreted to one of the real implementation.
Am I wrongly interpreting you?

> 	The important issue from my point of view is to try and get at how
> users and application developers want think about media.  I believe they see
> the key concepts as
> 	o the piece of plastic (disc) or whatever that actually holds the data
> 	  or in other words the volume ('HomeVideos).
> 	o the address or frame number or time code of the media segments they
> 	  are interested in 
> 	o the device on which that media has to be mounted

I don't really agree them.  I think what they care is a type of
media clip which is necessary because it determines available
operations, and everything except that is out of their concern.
Whether the device is mounted or not and sort of things should be
taken care of inside media objects I believe.

In my draft I put in /mit/musedev/doc/AM2/DS/media.fm,
media clip of type Graphics is abstract, but it is guaranteed
that the media clip will understand message "load" and "display".
I was envisioning checking the mount would be done in "load".

Lynne and Evelyn, I'd like to know your impression on
what you would like to see media-specific information in ADL,
no it's not correct, it's not what, but "how".
(And probably we should have started from that...)

> 	I would add that I think they are only interested in the device to the
> extent that the same device can't be doing two things at once.  That is, I
> don't think they care what model videodisc player is attached or what baud rate
> it communicates with, but they will care if they are running an application
> that requires two players when their workstation only has one.  I do not
> think they care at all whether the videodisc is managed by Galatea, DEC's
> MediaServer, or QuickTime.

Let's hear from Lynne and Evelyn.  But in any case media-specific
information has to be linked with its implementation (Galatea/QuickTime...),
and probably that can be done only in ADL (putting them in resources
is just a redirection of the information).

> 	The volume and media address are implementation independent because they
> correspond to actual physical units, a particular videodisc or CD-ROM.  They
> are application specific but not platform specific.  Frame 1234 is frame 1234
> whether you play the videodisc on a Mac, Windows or UNIX system, no?  What am
> I missing here.  I think we must be misunderstanding each other.

Right...  I have been feeling the same and that makes me troubles...
It's necessary for me to clear our misunderstanding to go any further
(and to write my part).

Now back to the discussion..

So your 'analogVideoStill implies the device is a disc, then
you need another fully qualified type for QuickTime still and
one more for still from network.

> 	Most of the time, I expect ADL won't do anything with the volume name
> unless the user programs it into the application.  For instance, the developer
> might have to tell the user that it is now time to change discs.

My media clip object for graphics would always check whether
associated engine is in proper condition or not when it is
received a message "display".  If there's any difficulty,
it at least can return an error message.

> 	There are two issues here.  I can easily imagine a system with several
> peripherals attached that would all fall under the category of MDgraphics,
> e.g., a videodisc player and a CD-ROM drive.  How is the user going to tell the
> media engine where to look for the clip?  Does the application developer need

By the argument when they specify a clip.

> media engine where to look for the clip?  Does the application developer need
> to know where the data comes from?  Well, doesn't he or she have to?  I mean

Nooooooo!  They can forget about the argument (volume name) once
they described it in ADL.

> basic points.  But any model we come up with will have to deal with the
> pathological cases too.  90% of software maintenance is taken up with getting a
> program to run correctly in modes it encounters only 10% of the time.  Sigh.
> Take it from one who has been fixing AM1 bugs for Ebe for years.

I totally agree with you on above. :-)

> 	Let me know if this clarifies things at all.

Sorry for sending such a long message.  But e-mail is sometimes
better methods for me than discussion (I'm slow in reading/writing
in English, I sometimes miss what you said in discussion... sigh)

Jud, I know you are extremly busy so I really appreciate you responded
me. But I definitely need a little more help from you at least until
we can clear our misunderstandings.  Otherwise I can't go further
and meet with Lynne and Adam.  Please persuade me (I'm very easy),
or be persuaded by me or let's invent another method.


					--- Toshi