Message-Id: <9302051750.AA00127@Athena.MIT.EDU>
Date: Fri, 5 Feb 93 12:50:05 EST
From: Toshiharu Harada <harada@ceci.mit.edu>
To: aybee@Athena.MIT.EDU, jud@ceci.MIT.EDU, lynne@Athena.MIT.EDU,
        pbailey@ceci.MIT.EDU, schluss@Athena.MIT.EDU
Cc: sigmund@nora.hd.uib.no
Subject: let's think it again

(I feel my head lighter...)

In this mail, I'd like to think about the whole things again
quickly.


				--- Toshi
---

Where shall we start from?  I think the answer is an issue of
"how should media-specific ADL description look like" because
theoretically we implement whatever shceme.

(1) ADL

principle: all the information that is needed to "present"
	   specified media information has to be described in ADL

Genericly speaking, those information might be categorized
as the following:

	(1) service		(Galatea/QuickTime...)
	(2) device		(volume name/file or CD-ROM or...)
	(3) address		(frame ID/"time")
	(4) others		(fps/?)

In Spite of how they appear, those set of information has to be
"authored" by AM2 application writers.  The description
may be done directly as was proposed in my scheme, but that is
not necessary.  In the latter case, somebody has to interpret
given ADL descriptions to complete four specifications.

Examples of ADL description:

	(a) "GALATEA", "Ozone:0, 1234"		... direct
	(b) AnalogVideo, "Ozone:0", "1234"	... indirect

The same string "Ozone:0" appears in both examples, however
the meanings are different.

In (a), "Ozone:0" is an ADL string, and will be just passed to
specified service (Galatea) without no interpretation.
In (b), on the other hand, "Ozone:0" is independent from
AnalogVideo media type and therefore ADL has to define its
syntax and also guarantee it will be properly interpreted to
a service which is associated with "AnalogVideo".

Among other things, the best thing with indirect description
is it will allow ADL scripts to be portable.  Let's see detail
of this in the next section.

---

(2) Portability of ADL

Say we have a service that is equivalent to Galatea in functionality
on Mac, and it supports the same concept of Galatea's volume,
the following ADL description probably will be able to shared
among UNIX and Mac platforms.

	clip := AnalogVideo, "Ozone:0", 1234-2000

Although I admire it will be really nice, I feel the propositions
we put are very restrictive and the portability can't be expanded
widely.  How do we deal with a service that allows to control
multiple diskplayers but requires player-ID instead of volume name
(yes, "volume name" is a Galatea's concept).

How can

		player-1, 1234-2000

be decoded from the above ADL example, in other words, who
will interpret Ozone:0 to player-1?  You might think "Ozone:0"
is stored in DB and refered by ADL, but in that case, ADL is
not truly portable, isn't it?

Another difficulty I noticed is if we have two services (for instance
Galatea+) that are similar each other and take exactly the same
arguments, they can no more share the same ADL and we will end up
with introducing something like AnalogVideo2.

I have pointed out two difficult situations for AnalogVideo,
however other media types seem to be worse.  For instance,

	FileStill, "TIFF", "/mit/musedev/data/ceci"

will never be portable on Mac.

As a result of those consideration, I think it is impossible
to make ADL scripts portable across platforms completely
although for rare cases such as videodisk and audio-CD
we may be able to do it.

... when I wrote the last sentence I received e-mail from Lynne
    it may be time for this message to go out ...

[ to be continued ]