Re: Toward a new WWW client architecture (was: Re: Local program execution (Yechezkal-Shimon Gutfreund)
Date: Thu, 21 Apr 1994 19:33:13 +0200
Message-id: <9404211728.AA08065@kesser.cisl214>
Precedence: bulk
From: (Yechezkal-Shimon Gutfreund)
To: Multiple recipients of list <>
Subject: Re: Toward a new WWW client architecture (was: Re: Local program execution
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

] From Thu Apr 21 00:49:53 1994
] Here are my thoughts, for whatever they're worth, on breaking up
] clients (which I think is a great idea.)
I think you have some very good concepts here.

] It seems to me you want to have accessories able to have access not
] just to the current "main" document but also to additional document
] information (essentially, those documents in a "local cache" of sorts,
] maintained by the main daemon.)  My apologies if you already were
] thinking in terms of something like this being plausible.

Yes, But I have not decided what that list of shared resources
is. Indeed, I probably would prefer some sort of software CAM
as I proposed in the Orchestrator paper


] Sample use: Suppose, with high cache hit rates mitigating the
] influence on the net, a client does anticipatory fetching; it does a
] GET, or at least a HEAD, on all the links pointed to by the current
] document.  This information is employed by many different accessories;
] for instance, the HTML viewer may represent links that seem not to be
] fetchable in a special way, while an accessory for displaying a graph
] mapping the current hypertext structure (using REL and REV tags to do
] so in a meaningful way) uses that information (e.g. represent larger
] documents as bigger circles, represent content-type information with
] colors, or whatever.)

Wow. The anticipatory fetching (shades of branch pre-fetching) is a
great idea for a plug in module. Thank you.

] For that matter, presumably there will be something (I'll call it an
] "window" though I'm not sure that's the best way to describe it) which
] constitutes all active applets with a given main document; there seems
] no reason not to allow multiple windows with the same (or different)
] applets tuned to a different "main" but using the same underlying
] "daemon" for handling interacting with servers with various protocols,
] doing caching, etc, though each window would have its own "conductor."
] Sensible?

I think at this point we get into a philosophy of interface discussion.

For me, I am STRONGLY in favor of multi-modal user interfaces. That
is I (taking after Bill Buxton) like to be able to use multiple simultaneous
instruments to express my desires to the program. 

Buxton has a very nice example of this. He claims that the program interface
should be like a musical insttrument interface (e.g. oboe). A rich
interface with multiple modes of interaction. Current mouse based
interaces reduce a person to a cripple with one finger. A very limited
means of expressing oneself.

However, I am not sure I want these multiple artifices to be connected
simultaneously to multiple "applications". That is, if I am controlling
a jet fighter, I do not want one of my applet interfaces to be both
controlling the engines and the brightness of the panel lights.

This is why I tend to focus on a model of a single "main" document - with
applets providing additional accessory documents that operate
in tandem with the main document.

However, I may be missing the point you are making.

] It might be useful for applets to communicate with each other,
] including possibly applets in different windows.  For instance, if I'm
] composing a document and have a document in the other window I want to
] create a link to, "sticking" the existing document into the editor
] document might be one way to do so.  Something of a drag-and-drop
] nature comes to mind, but I'm not sure.

I am sure they will communicate with each other. The question is
what model do we use for communication? I prefer these sort of intelligent
blackboards/Software CAMS/tuple-spaces. It it easy to do what you
are asking in the next paragraph:

] One minor disadvantage is the fact that applets/accessories presumably
] would not have intimite access to the activities of the daemon, which
] would make it difficult for it to display things like the byte count
] of a transfer in progress.  It may be desirable to have the daemon act
] as an applet displaying a status box, or something like that.

Here I would have the deamon constantly updating a byte count register
in the shared tuple space. That way a byte count displayer applet
could be mapped to give the running byte count. For that matter,
a debugger applet could be mapped that would display all sorts
of interal information about the daemon as it is operating. 

Currently I am converting my Orchestrator to TCL-DP. So it should
be ready when TK4.0 comes out to use. Performance is quite encouraging.
I am getting over 2000 tuple operations/sec, on a single Ethernet

] Best of luck; I really hope something like this works.  It would add a
] lot of flexibility and open things up to innovation a lot more than a
] monolithic client that few people can understand or enhance.

Yechezkal-Shimon Gutfreund [MIME]
GTE Laboratories, Waltham MA