]
] 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
(ftp://ftp.gte.com/pub/circus/papers/CircusTalk.ps)
] 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
segment.
]
] 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 sgutfreund@gte.com [MIME]
GTE Laboratories, Waltham MA ftp://ftp.gte.com/pub/circus/home/home.html
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=