Fast path to a portable Transcopyright browser

[oster@xxxxxxxxxx (David Phillip Oster)]

How much of the browser needs to be "our browser"? In particular, Sun has
done a good job of getting the world to agree to support Java, which in its
current design cannot be retrofitted into existing browsers via helper
applications. Java requires all new browsers, and Sun has convinced Netscape
to build Java in, making it a de facto standard.

The reason this is interesting is that Java is specifically designed for
writing portable code that manages: 

Applets - Java's name for a piece of code that managaes a portion of a browser
window, drawing images there, and handles the user clicking or typing
on that portion of the window

Protocol handlers - Java's name for a piece of code that manages an i/o stream
with the net referenced by a URL that starts with a token for that
protocol. For instance xu://whatever@xxxxxxxxxx would cause a piece
of java code called xu.class to run.

Content handlers - Java's name for a piece of code that manages an i/o stream
with the net that is a MIME type that matches the token for that
handler. For instance, gif files, vrml files, and au sound files are
all distinct MIME types, so would be handled by distinct content
handlers.

What this all means is that a large portion of a Transcopyright-aware 
browser should be prototype-able inside any Java aware browser. This lets
us concentrate, right from the start, on interesting issues, without needing
to dive in and do a whole browser.

Since you can link C code into Java, for those environments that support
irrregularly shaped windows, which may also float above any application,
this allows cross-window arrows to be implemented as a special kind of
arrow-shaped window, that moves in response to inter-task communication
messages sent to it by the applets that are managing space in browser
windows. In particular, I can do this on a Macintosh.

What do you think?
-- David Phillip Oster