> I'd like to see the CCI idea expanded to a full-blown "message bus"
> ala tooltalk.
> In fact, maybe all this technology is overkill for the problems at
> hand. We'll see...
That's something I've been grappling with: What technology is a reasonably
doable and sufficient subset, which are likely to be commercially
successful ( which means we may have to come to terms with them,
proprietary or not ) and which are more-open/less-proprietary than
others ( and thus, which would I rather see be successful! )
I have some notes and links at:
<http://minsky.med.virginia.edu/sdm7g/Projects/Python/SafePython.html>
These started out as notes on "safe Python" for the NIST Python
workshop, however I was also trying to look at other distributed
object technologies and figure out what was not overkill ( I
don't think any of this is really "overkill" - I mean what is
digestible and usable in the near term. )
Safe-Python is an interpreted-language remote agent approach that would
safely allow client and server to send each other executable code.
[ The two major modifications to the Python interpreter I discuss
are in place and being tested in the current (limited-distribution)
Python 1.1.2 beta. There are still some back doors to be plugged
before I would trust it as reliable safe agentware. Also, a lot
of documentation and examples to be written. ]
However, despite the fact that I'm working on a language based solution,
I've expressed by doubt that a procedural language ( vs. a protocol or a
data representation ) is a likely way to standardize interaction.
( And that's one of the reasons I've been looking at other technology -
looking for a common protocol for agents and programs written in
different languages to negotiate and interact with each other. )
> There's an "open" platform for experimenting with these issues too:
> the X11R6 version of ICCCM[4] specifies conventions for embedding one
> X client in another (like some ghostview and MidasWWW do with the
> embedded gs window).
I'm not up on X11R6, but isn't Fresco supposed to provide the
capability to write OpenDoc-like embedded documents.
> I'm not sure how using ILU would help you deploy on Mac/Windows
> platforms.
The was a Mac port of an earlier version of ILU.
I don't believe the current release has been ported.
I'm still looking at OpenDoc/SOM/OSA (Open Scripting Architecture)
vs. ( or maybe in addition to, somehow interoperating ) ILU, but
I don't have enough application experiences with either yet to
say much.
> I think a set of user interface conventions for hypertext GUIs will
> evolve over the next year or so. Just like cut/copy/paste and the File
> menu, we'll see some combination of buttons, menus, and drag-n-drop
> idioms evolve into a desktop standard. Maybe by then X will be a
> usable desktop platform. Maybe...
> Apparently some of the Mac internet tools interoperate in sophisticated
> ways like this... Anarchie, Eudora, and MacWeb apparently sling URLs
> around invisibly for the user through applevents[9].
Apple's Open Scripting Architecture ( one of their contributions to
the OpenDoc technology ) may just be one of those pieces that is not
too big to bite off and chew. (OSA does not depend on the rest of OpenDoc)
OSA is a higher level protocol - it defines an API and tries to
standardize suites of messages that applications can send to each
other. AppleEvents will become OpenEvents in the portable API.
One the Mac, they will be implemented by - guess what! - AppleEvents.
The implementation on other platforms may be different, and in
fact, it is not yet determined how these events will be supported in a
distributed environment. I had been assuming via CORBA compliant DSOM, but
I have been told that hasn't yet been decided. ( OpenEvents could likely
be mapped onto ILU for a SOM-less portable distributed OSA implementation.
Incompatible, but easily gatewayed to a native AppleEvents or other
implementation. )
A postscript paper and other info describing OSA is at:
<http://minsky.med.virginia.edu/sdm7g/Projects/Python/OSA/>
I'm not necessarily recommending OSA, ILU, or OpenDoc as a solution -
I'm still trying to digest this technology. But I think this sort
of direction is the way for the Web to go. The Web is really a sort
of poor man's distributed object system already. Lot's of MIME typed
objects but really only two "messages" ( 'display' and 'show source' )
In fact, it was the Web as an example of a reasonably doable subset of
compound-documents/distributed-objects that inspired me to look for
the next reasonable step.
Links and references to OpenDoc, SOM, ILU, etc. are all in there
*somewhere*. Sorry it's not in better order - it's just a snapshot
of my working notes. I have other material to organize and deposit
there when I find the time.
---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---