The WorldWideWeb is a powerful medium which has many applications beyond just publishing static documents. It is certainly an interface to the space of "documents." But already, with established features such as input-forms and server-side scripting, we see that the web is also increasingly becoming an interface to the space of what is traditionally called "applications."
And, to support all the ever inventive and encompassing uses of the web, browsers are called upon to have ever more features. But, however judiciously browser designers choose the features to implement, a consequence is that many browsers tend to be able to do many things, but also tend to be fairly shallow in each area.
A thing is to not just standardize on the specific features that we want in browsers. But, also importantly, I think, is to standardize on an extensible architecture so that the web software can grow incrementally.
Here are some obsesrvations which make a dynamically extensible architecture look like a good thing to have.
One, creeping featurism leads to to really big programs. Not good. It would be nice to have an architecture such that people with special needs can plug in an additional, or replacement, module that solves their particular problems.
Otherwise, programs get really big, and 90% of all users use maybe 10% of the features.
Two, with the server side scripts, we're seeing lots of documents that are really front-ends to what are traditionally call "applications". This basically goes with the trend of the bluring line between applications and information. And generally the merging of various technologies.
Three, without an easy extensible architecture, special interest groups might end up needing to make special modifications to the software, and then we would end up with different version of the same browser.
There are other problems which argue for the idea of extensible software, but we won't go into them here.
We already do "extend" browsers with things like "external viewers." But there's not a very good integration with the browser. Ideally those external viewers should be rendering in-place inside the document, and be working together with the browser, be tightly integrated with the browser and other parts...
So, a solution is what's been touted under with name "component software". The basic idea is that, rather than buildig one single monolithic application that does everythig from day one, we should be building a framework or architecture that ican be dynamic in its ability to have functionality added or deleted on the fly.
Those component parts can be many different things. For example, such parts could be: special navigation control, visualization controls, self guiding slide show presentation tool, and so on.
For more on this issue, see "http://www-pcd.stanford.edu/workshop/slides/wei/talk.html".
This is the Viola system that is being developed at O'Reilly and Associates. This system has the following interesting characteristics:
One, it has a relatively small core engine. A toolkit with the primitives coded in C.
Two, an extension scripting language for implementing and glueing together applications. For example, the Viola WWW browser applications is built using the Viola toolkit.
Three, program objects can be embedded into documents and the toolbar. For example, this is a little bookmark tool embedded into the ViolaWWWW's toolbar. This tool is linked to the document, and so comes and goes with the document.
This is a little mini chess board application that is published on the web server, and instantiated locally by the interpreter. A nice thing is that you could have high interactivity without incurring a lot of bandwidth -- you can move pieces around, and the board can do simple checks for illegal moves, and transmit only the essential movement information... As opposed to using the ISMAP feature and transmitting a new chess board picture for every move.
This way, you're minimizing the client-server traffic, and maximizing user interactivity.
OK, to get some concrete ideas on how to build such an applet, lets build a little time/date display applet that continuously update itself, and then show how to embed that applet in a HTML docuemnt.
First, enter this app into a file:
Save that file under the name "showTime.v", and put it somewhere that a web browser can get to it (doesn't matter whether it's via file: or http:).
Now, use ViolaWWW to load that file, and you'd get a "page" that's just the showTime app. It might look like this:
[screendump of browser showing app]
Hopefully at this point it's clear that this opens up a lot of possibilites. OK, but what if you want to embed that applet inside of a document? You can do so with the <LINK> tag like this:
Of course, you could replace the URL above with one that points to your copy of showTime.
You should get:
[screendump of the page with app embedded].
At this point you're probably thinking how great this this, but how do I know that the applets I run won't delete my files, smuggle info out of my system, and do other mischiffs?
The answer is that these imported objects can't (or shouldn't be able to).
The current security policy is pretty straightforward and somewhat limiting for the objects. It basically goes this way: all imported objects are marked as untrusted, and as such these imported objects have no system priviledges, have no access to sub interpreters, and can not coarse other objects to execute scripts arbitrarily.
Done using Security flags, why, what, how?
If an object is "unsecure" it can't change its own security rating. It can't execute tweak() because.... It can't execute system() because.... It can't execute interpret() because....
Remaining problems?
multi threads in language
name space
mesasge relay
[talk a little about how the chess board app can at the same time dramatically minimize bandwidth and maximize performance]
[the basic idea sending small scripts which can recompute the GIF, rather than sending the relatively much bigger GIF data... example:]
The class hierarchy tree: as classHier.gif, it's 8572 bytes; as script, it's 2720 bytes (1/3 of the GIF size).
But more interesting is if you could make that tree graph do the following things
To do that, the script will be bigger than the 2720 bytes, but to be about 4519 bytes, which is still about half the size of the GIF.
[insert a simple to understand table showing the differences]
Listed below is the simpler ersion of the script. The script to implement the active graph is online. It consists of three objecst and basically works this way: there's three objects. One object containing the information of the nodes (size, location, and label of the nodes) and some scripts; A second object that's the template for any node. This object is cloned many times, as many times as there're nodes as specified by the first object, and the individual clones are modified to 'be' the nodes in the tree. A third object that's just a text label used for the graph legend.
Signaling applet its in-view status:
Be sensitive to "VIEW_ON" and "VIEW_OFF" which ViolaWWW sends. This allows embedded objects to know when it's not in view of the use, and thus may cease on certain activities.
Ie: no point drawing when there page isn't in view.
[talk about the uses of a non scrolling region for plugging-in programmable tools/applet such as navigational aids...]
How to embed... Use , and the object will be plugged int the toolbar area. Since the toolbar does not adjust height, you must take that into account-- don't insert applications too big for the spot. The height is normally xxx pixels, and width is about depending on the window...
There are many reasons why you might want to put applet in the toolbar instead of the document.
Some disadvantages:
So what can you do with this facility? Here are some examples:
[note that for simple nav icons, it's better to just improve HTML rather than use scripts... thou the point of the scripting language is that it provides a mean to implement such unanticipated applications possible]
Putting navigational icons in the toolbar.
The HTML markup:
The applet file:
The HTML markup:
The applet file: