Toward a new WWW client architecture (was: Re: Local program execution in WWW browsers
sg04%kesser@gte.com (Yechezkal-Shimon Gutfreund)
Errors-To: listmaster@www0.cern.ch
Date: Tue, 19 Apr 1994 22:23:39 --100
Message-id: <9404191949.AA04879@kesser.cisl214>
Errors-To: listmaster@www0.cern.ch
Reply-To: sg04%kesser@gte.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: sg04%kesser@gte.com (Yechezkal-Shimon Gutfreund)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Toward a new WWW client architecture (was: Re: Local program execution in WWW browsers
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 6608
In the last few days I have read over carefully the comments
of Bert Bos, Paul Burchard, and David Martin. It
appears that there is some convergence of opinion
here - and hopefully we can exploit it.
Let me try and wrap things up (as seen from my perspective):
Background:
o Several groups have been working on client side excutable code:
examples include the George Phillips exec:// hack and safe-tcl.
o Some of us feel that we would prefer a more systematic extention
to the WWW client - one that specifies a clear division of responsibilites
between accessories and host client - coupled with a well specified
communications protocol
o I have, in the past, proposed an extention to the Mosaic client that
was along these lines. I chose Mosaic, mainly because it was
a single clear reference point. Obviously, I was aware that what
I was doing had general applicability to all WWW clients.
I used that paper to try and discuss all ramifications that I could
see, and to analyze several radically different classess of accessory
tools.
I do not consider myself a prophet, and I am quite cognizant that
given any architecture that I proposed, it would be limited by
the scope and breadth of the classes of accessorory tools I
could envisage.
Therefore, I opened things up to try and get more input.
I tried to make my architectural additions incremental to the
current Mosaic, so that NCSA would "bite the bait".
Current state of Affairs:
o NCSA does not seem interested.
o We seem to have a core group who is interested, and would like
to put together a blue-print of a new architecture for WWW clients.
Perhaps getting this into the standards bodies or before the IETF?
Where to go Next:
o It looks like it is time for Plan II: scrap incremental changes
to the current set of WWW-clients, and go with a new plan.
I suggested this at the end of my paper:
Future Directions
Ultimately, one could imagine the Mosaic Viewer itself being
re-implemented as an accessory. Mosaic then would become an
background daemon process. This daemon process would act as a
master conductor, informing its accessories when a new document was
switched to, and arbitrating between the responses of the various
accessories. I believe this is the way that TkWWW now works. In such
a scheme we would have effectively OEM'ed the entire Mosaic
interface.
What this entails:
Let us first see if we can come to consensus as to a general overall
architectural blueprint.
Assumptions:
o A monolithic WWW client is a thing of the past. WWW clients should
be composed of a suite (flock) of small applets or accessories. Each
one performing a part of the task.
o OEM's will produce these accessories, and they will be packaged together
by system integrators to produce a WWW-client-suite.
o Items can be added and removed from the suite on the fly.
o The items will visually and semantically mesh together seamlessly.
Metaphor:
The home stereo component/TV/VCR/Nintendo center. While there is
obviously one "document" that is running on these centers at a time,
and one focus of attention. Each accessory component hightens the
effect, and makes use of the special characteristics of its medium.
E.g. the are the main speakers, the surround speakers, the main program
showing on the TV (e.g. from VCR), the live TV inset on the screen,
and the interactive controls.
Tools:
[Dave Martin's work with ICCM sound like it is something we should all
look at. But my gut reaction is that ICCM hacking is not the level
of attack that even he would prefer]
Let's assume we have either:
FRESCO on top of X11R6 (with CORBA types built in)
TK4.0 (also with embeddedable window objects)
Or
OLE 3.0 Which is what I think is the CORBA OLE V2.0 merge.
At least they are talking about some interapplication in OLE
in the Chicago release of Windows.
Therefore:
Given that we have the basic tools for live embedding of distributed
graphic objects - what should the architecture and protocol be:
Here is my take from my ACM MultiMedia'93 paper:
It is our belief that the basket of orchestration issues (section 3.0)
should not be handled in a piecemeal approach. Just as an orches-
tra needs a single conductor, so do the "performers" in a distribut-
ed multimedia ensemble. In an orchestra, there is a single
centralized decision maker who makes the scheduling, layout,
and arrangement decisions. Global issues of tonal balance, match-
ing layout to the hall's acoustics, and balancing volume across the
different pieces of the orchestra is not done on a piece-by-piece ba-
sis. Rather, there is a single centralized point of control where
these decisions are carried out. Nor is each orchestration issue han-
dled separately or sequentially. Instead, due to the interaction be-
tween orchestration issues, they are all balanced within one
sophisticated rule making system.
That is, I see the WWW-client suite as consisting of:
1. A central orchestration object. Whose job is to pull together
all the different accesories. Just like the home stereo/TV center,
there is basically one central activity going on - and all the
other activities are running in tandem - but they are basically
playing harmony.
2. A flock of accessory applications playing harmony
The outline of the protocol then is then not as hard as a general
purpose distributed programming problem. There is basically
one document under view at a time.
accessories basically rely ont he orchestrator for two services:
o being mapped to the composite window (I see a language like the
TK packer as being sufficient to start with).
o requesting (or suggesting) that the main document switch to
a different document
o receiving signals or messages from the orchestrator that the
main document has changed. And then they have the responsibility
of getting and subcomponent documents and "playing" them.
I would not try and centralize the interaction controls. Each
accessory in the stereo/TV system has its own unique GUI needs.
So too, I would want special hand-held remote-control forms
controllers to have their own interface.
I realize now, that I could keep going with this.
However, we need to figure out what sort of consensus we have, and
what sort of effort we should put into this.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Yechezkal-Shimon Gutfreund sgutfreund@gte.com [MIME]
GTE Laboratories, Waltham MA ftp://ftp.gte.com/pub/circus/home/home.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=