craig@gpu.utcs.utoronto.ca (Craig Hubley) (08/25/90)
DE FACTO and LEAPFROG approaches
After all this interesting furor about where types come from, and how they
get standardized, and what kinds of things vendors and standards committees
consider in making up their minds... I think we have delineated the two
main approaches to defining types: "de facto" and "leapfrog". Like top-
down and bottom-up design, they both tend to have their place in the sun.
IS MULTIMEDIA AN EXCEPTION ?
But there is still at least one unanswered question here: putting on our
"leapfrog" hats, is the ideal multimedia mail/document system different,
in principle, from the ideal general-purpose object manager ? That is,
is there something special about presenting multimedia/hypermedia objects
to a user that precludes the use of a generalized object manager framework ?
Are the architectures necessarily different ?
MANAGERS WITHIN MANAGERS
This is analogous, of course, to the old debate about whether objects should
have methods to display themselves, or whether a 'display manager' should do
it... in the first case, the general-purpose architecture of behavior, the
inheritance matrix, deals with presentation to users just as it deals with
storage to the filesystem. In the second case, the notion of 'display' is
itself encapsulated. The 'display manager' is itself built within the
general-purpose object management framework, which is essentially an object-
oriented operating system.
FACTORING FUNCTION
The issue, then, is not how to define the data type, but rather when to
associate the functionality directly with the type, and when to associate
it with the display manager.
Ideally, the functionality of a presentable object should be partially
determined by its nature and partially by its context... but this proves
to be difficult to adjudicate clearly, as Jon's example with the fixed
tabs shows. SGML takes a stab at this, defining the structure itself and
then expecting a compiler-to-presentation-mode to take over and produce the
actual, displayable form. But this may be like asking a machine to take a
lot of film stock and direct "The Seven Samurai"... it is unclear how useful
this approach is going to be with directly perceptible types like graphics and
sound, which are very sensitive to the smallest presentation difficulties. As
people try to build complex presentations with tools like troff or TeX, they
seem to end up doing more and more low-level programming, and getting *around*
the powerful formatting engines - and these are the most mature systems of
their kind, in a very mature medium, stylistically, the printed page. So
maybe we all end up hacking something like PostScript anyway. This is not
to say that abstracted notations fed to powerful preprocessors are not useful,
they are: I can do a hell of a lot with LaTeX, and never touch TeX itself.
DRAWING THE LINE
So where does the 'nature of the object' lose its relevance, and when do I
have to start hacking to give it a context ? Is there any other way to give
it a context ? One that we feel comfortable standardizing ?
I am going to be away for a couple of weeks, and I won't be reading mail,
and since I get the newsgroup rather than the mailing list, I may miss a
few messages unless I get put on the mailing list temporarily. What's the
request address?
Thanks,
Craig Hubley kid after Live Aid: "Is that it?"
Craig Hubley & Associates ---------------------------------
craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET
craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig
28 First Avenue, Suite 2, Toronto, Ontario M4M 1W8 Canada (416) 466-4097
--
Craig Hubley kid after Live Aid: "Is that it?"
Craig Hubley & Associates ---------------------------------
craig@gpu.utcs.Utoronto.CA UUNET!utai!utgpu!craig craig@utorgpu.BITNET
craig@gpu.utcs.toronto.EDU {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig