Chapter 13

Extensibility and Mini Applications

Why is Extensibility Important?

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.

Possible Ways to Extend Browsers

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 "".

Viola's apprach

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.

How to build such an applet?

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:

\class {txtDisp} \name {showTime} \script { switch (arg[0]) { case "tick": set("content"), date()); after(1000, self(), "tick"); return; break; case "init": after(1000, self(), "tick"); break; } usual(); } \width {100} \height {50} \

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:

<HTML> <P>And, the time now is: <LINK REL="viola" HREF=""> </HTML>

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].

Security Issue

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

Using Scripts to Minimize Bandwidth Requirement

[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.

\class {field} \name {chier} \children {chier.label} \script { /* This is a demonstration of a tree "widget" built using the * viola language/toolkit. Although a non-standard technique, * this is a useful way to extend the basic HTML, if you need it. */ switch (arg[0]) { case "expose": if (once == 0) { tt = get("content"); n = countLines(tt); for (i = 0; i < n; i++) { ll = nthLine(tt, i); super = nthWord(ll, 1); class = nthWord(ll, 2); obj = send("chier.temp", "clone"); objectListAppend("children", obj); xy = send(obj, "be", super, class, nthWord(ll, 3), nthWord(ll, 4), nthWord(ll, 5), nthWord(ll, 6)); if (xy) { segs[segCount] = xy; segCount++; } } once = 1; } for (i = 0; i < segCount; i++) { xy = segs[i]; drawLine(xy[0], xy[1], xy[2], xy[3]); } return; break; } usual(); } \width {500} \height {450} \BGColor {LemonChiffon1} \BDColor {LemonChiffon1} \FGColor {black} \content {0 cosmic 49 12 65 20 cosmic generic 122 67 83 20 generic field 199 110 61 20 field BCard 373 196 71 20 field FCard 330 224 72 20 field XBM 273 250 70 20 XBM XBMButton 296 312 95 20 XBM toggle 398 299 63 20 toggle radio 434 348 58 20 field XPM 198 249 57 20 XPM XPMButton 193 316 95 20 field dial 438 37 51 20 field client 43 223 64 20 client socket 1 260 58 20 client tty 38 286 48 20 field menu 437 10 50 20 field pane 120 246 51 20 pane hpane 67 313 54 20 pane txt 98 340 46 20 txt txtLabel 92 389 80 20 txt txtButton 1 394 83 20 txt txtDisp 180 389 76 20 txtDisp HTML 210 424 68 20 txtDisp txtEdit 125 424 77 20 pane vpane 132 314 56 20 field project 412 170 70 20 field rubber 436 90 62 20 field slider 435 117 60 20 field stack 437 64 60 20 field tray 426 144 60 20 } \ \class {txtButton} \name {chier.temp} \parent {chier} \script { switch (arg[0]) { case "reportLink": return xy; break; case "be": /* This is the template object for the tree-graph-nodes * * arg[1] superclass name * arg[2] class name * arg[3] x * arg[4] y * arg[5] width * arg[6] height */ superClass = arg[1]; thisClass = arg[2]; set("name", concat("chier_", thisClass)); if (superClass != 0) superObjName = concat("chier_", superClass); else superObjName = 0; set("label", arg[2]); set("x", arg[3]); set("y", arg[4]); set("width", arg[5]); set("height", arg[6]); set("visible", 1); xy[0] = x() + width() / 2; xy[1] = y() + height() / 2; if (superObjName) { pxy = send(superObjName, "reportLink"); xy[2] = pxy[0]; xy[3] = pxy[1]; return xy; } else { return 0; } break; case "buttonRelease": url = "violaChier_fail.html"; send("www", "show", udi); break; case "clone": return clone(0); break; } usual(); } \BGColor {LemonChiffon2} \FGColor {black} \BDColor {black} \font {normal} \ \class {txtDisp} \name {chier.label} \parent {chier} \content{The Viola Class Hierarchy, as of November 1993} \BGColor {LemonChiffon1} \BDColor {LemonChiffon1} \FGColor {black} \font {normal} \x {305} \y {390} \width {180} \height {60} \

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.

case "tick": /* do work */ if (view == 1) after(1000, self(), "tick"); return; break; case "VIEW_ON": view = 1; after(500, self(), "tick"); return; break; case "VIEW_OFF": view = 0; return; break;

12.2 The Dynamic Toolbar

[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]

Nav Icon

Putting navigational icons in the toolbar.

The HTML markup:

<HTML> <LINK REL="tool" HREF=""> </HTML>

The applet file:

\class {XBM} \name {nav-icon-to-violaHome} \script { if (arg[0] == "buttonRelease") send("www", "show", ""); usual(); } \label {#define violaIcon_width 39 #define violaIcon_height 31 static char violaIcon_bits[] = { 0xff, 0xff, 0xff, 0xff, 0x7f, 0xff, 0xff, 0xff, 0xff, 0x7f, 0x03, 0x00, 0x00, 0x00, 0x40, 0x03, 0x00, 0x00, 0x00, 0x60, 0x03, 0x00, 0x00, 0x00, 0x40, 0x83, 0x3f, 0x00, 0x00, 0x60, 0xc3, 0x61, 0xf0, 0x00, 0x40, 0x63, 0xc0, 0x98, 0x03, 0x60, 0x33, 0x80, 0x0f, 0x06, 0x40, 0x13, 0x00, 0x03, 0x06, 0x60, 0x1b, 0x00, 0x00, 0x0c, 0x40, 0x0b, 0x00, 0x00, 0x8c, 0x62, 0x0b, 0x00, 0x00, 0x8c, 0x42, 0x0b, 0x00, 0x49, 0xff, 0x67, 0x0b, 0x1e, 0x00, 0x80, 0x42, 0x0b, 0x1e, 0x00, 0x80, 0x62, 0x0b, 0x1c, 0x08, 0x80, 0x42, 0x13, 0x1c, 0x08, 0x00, 0x60, 0x33, 0x38, 0x08, 0x00, 0x40, 0x63, 0x38, 0x04, 0x08, 0x60, 0xe3, 0x33, 0x14, 0xe8, 0x40, 0xc3, 0x73, 0x04, 0x08, 0x61, 0x83, 0x63, 0x92, 0x09, 0x41, 0x03, 0x40, 0x52, 0xca, 0x61, 0x03, 0xc0, 0x52, 0x2a, 0x41, 0x03, 0x80, 0x53, 0x2a, 0x61, 0x03, 0x80, 0x91, 0xc9, 0x43, 0x03, 0x00, 0x01, 0x00, 0x60, 0x03, 0x00, 0x00, 0x00, 0x40, 0xab, 0xaa, 0xaa, 0xaa, 0x6a, 0xff, 0xff, 0xff, 0xff, 0x7f}; } \BGColor {grey45} \BDColor {grey45} \FGColor {white} \width {39} \maxWidth {39} \height {32} \

Book Mark

The HTML markup:

<HTML> <LINK REL="viola" HREF="">

The applet file:

\class {menu} \name {bookMark} \script { switch (arg[0]) { case "buttonRelease": send(parent(), "go_home"); break; case "freeSelf": bell(); break; case "visible":/* temporary */ set("visible", arg[1]); return; break; } usual(); } \menuConfig { .{Following links} {send("www", "show", "#links");} .{Going Home} {send("www", "show", "#home");} .{Bookmarks} {send("www", "show", "#bookmarks");} .{History} {send("www", "show", "#history");} .{Tearout} {send("www", "show", "#tearout");} .{Keyword Search} {send("www", "show", "#search");} .{Printing} {send("www", "show", "#printing");} .{Source viewing} {send("www", "show", "#source");} .{\\} .{Demo} {send("www", "show", "violaWWWDemo.html");} .{\\} .{Dismiss this menu} {send(parent(), "removeTool", self()); freeSelf();} } \label {Viola GUI help} \BDColor {white} \BGColor {grey45} \FGColor {white} \font {normal} \width {150} \maxWidth {150} \height {30} \gapH {2} \gapV {2} \
GOTO Preface, Previous Chapter (12), Next Chapter (14)