Message-Id: <9302032315.AA27948@Athena.MIT.EDU>
To: harada@ceci.mit.edu
Cc: jud@ceci.mit.edu, aybee@Athena.MIT.EDU, pbailey@ceci.mit.edu,
        lynne@Athena.MIT.EDU, sigmund@nora.hd.uib.no, schluss@ceci.mit.edu
Subject: 
Date: Wed, 03 Feb 93 18:19:22 -0500
From: Judson Harward <jud@ceci.mit.edu>


Toshi,

	Thanks for your thoughtful memo. Let me try and respond.

  >  Issue: "how should media-specific description look in ADL (with example)"

	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

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.

	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 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.

  >  Issue: "how those description can be linked to their implementations"
	(discussion will not make sense without mentioning to the latter)

	Well, I can see a number of ways this can be done.  First thing is that
the mapping from "fully qualified media type" to implementation is platform
dependent, installation dependent, and often workstation dependent (e.g., some
workstations have Panasonic videodisc players, some don't).  Possible strategies
in order of increasing specificity, that is, the later ones override the
earlier:
	1) a table coded in the DDX layer that maps from "fully qualified media
	   types" (FQMTs) to implementations.

	2) an assignment or message in the application ADL code

	3) a resource in the application's platform specific resource file
	   (This last was Wissam's suggestion).

  >  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.

	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.

	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 developper
might have to tell the user that it is now time to change discs.

  >  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?).

	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
to know where the data comes from?  Well, doesn't he or she have to?  I mean
out of all the videodiscs out ther in the lab, you only get the full effect of
suburbs if you put the right videodisc in the machine :-).  Yes, the
application developer cares.

	I agree with you.  Let's delay discussion of the pathological cases
like changing discs in mid-application, until we have agreement on the more
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.

	Let me know if this clarifies things at all.

							Jud