Re: PROPOSAL: "W3A" - a client-side applets API

"Daniel W. Connolly" <>
Date: Fri, 24 Jun 1994 21:30:24 +0200
Message-id: <>
Precedence: bulk
From: "Daniel W. Connolly" <>
To: Multiple recipients of list <>
Subject: Re: PROPOSAL: "W3A" - a client-side applets API 
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
In message <>, Bert Bos writes:
>After several false starts, including forays into FIFOs, TCP, and X
>events, I have finally found a model for WWW `accessories' that looks
>simple, yet powerful.
>Could this be the key to unleashing the myriads of ideas about viewers
>and accessories that people have, but until now couldn't implement...?
>Reactions, please!

First, thanks for making this available. Great food for thought.

There are two groups of issues: the interface definition, and the

Your implementation is limited to Unix boxes that support dynamic
linking. That's OK as proof-of-concept, but any effort in this area
really should ultimately be usable on MS Windows and Macs too.

But the important thing is to get the interface definition right. Once
you've got that part right, porting it to various languages and
platforms is just a matter of nitty-gritty details.

I've done a lot of prototyping based on the interfaces in libWWW. Most
of my prototyping has been in python, just for rapid development of
ideas. It's also nice to not have to worry about memory allocation
junk while prototyping.

Anyway... you're interfaces are almost like the libWWW interfaces, but
not quite. They lack some things, and in other places, they're just
different in ways that can be resolved:

 * The "objects" in these interfaces (the browser, for example) are
implicit in the function calls, causing the state for the objects to
be stored in global variables.

 * It doesn't allow browsers to "prefer" one format over another.

I can't remember the other interface problems that I saw...

Other issues that I have yet to see satisfactorally addressed anywhere:

 * A hypermedia document architecture that accomodates
   compound/complex documents with links between them. MIME makes a
   good framework for coarse-grained composition (but the multipart/*
   encoding is designed for internet mail, rather than reliable 8bit
   data pathways and so it's not very efficient), and SGML works OK
   for structured text, but something like Bento is probably what we
   really need. HyTime ideas should play a part here too.

 * There is no coherent exception mechanism (i.e. no error handling model)
   (Python's exception model works well)

 * We need two kinds of "safe" programming languages: the
   lisp/perl/smalltalk/python style safe language where the programmer
   can't screw up the runtime system the way one can with C and C++,
   and the safe-tcl/Obliq/telescript style safe language where
   untrusted code can be run with bounded access to resources.

I've been looking into development technologies for allowing folks all over the
net to contribute. Python looks good, but scheme48 from MIT also looks promising,
though less mature. WINTERP-2.0 looks great too.

Check out my research notebook for all sorts of stuff like this:

Also, folks might want to check out the python code for the www
browser I used to test out my interface definition work. The python
interpreter I use to run this stuff has Motif, the HTML widget, and
SGML.c from libWWW all linked in. So you won't be able to run the code
as-is. But parts of it should be useful.

By the way... I'm pretty sure the next release of Mosaic will have
some sort of plug-in interface. I'd sure like to review the design of
that thing before the whole world starts using it! If anybody sees a
write-up on it, let me know!!!

Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010