Right now, the ViolaWWW that is under development can embed viola
objects/applications inside of HTML documents. This is useful in that,
for example, if you needed a hyper-active tree widget in your HTML
document, and HTML+ doesn't happen to define it, you could build it as
a mini viola application. Same thing with customized input-forms that
could conceivably do complicated client-side checking. Or, complex
tables. Or, a chess board.
You'd basically have a simple GUI toolkit and language at your disposal,
along with HTML.
To make this a bit more concrete, here's an simple example of one
viola object being embedded into a HTML doc.
-----------------------------
<P>Watch Big Bird count from zero to infinity:
<LINK REL="vobj" HREF="http://sesame.st/count.v">.
-----------------------------
Listed below is what the file "http://sesame.st/count.v" would look
like, just to give people a feel of the language:
-----------------------------
\class {txtLabel}
\name {count}
\script {
/* This object counts and displays
*/
switch (arg[0]) {
case "setup":
/* arg[1] == parent object
*
* Convention sez to link to the parent object (the
* document object).
*/
set("parent", arg[1]);
after(50000, self(), "tic"); /* start counting in ~5 secs */
return;
break;
case "tic":
/* Increment and display. Call self after 10000 micro secs.
*/
set("label", n++);
render();
after(10000, self(), "tic");
return;
break;
}
usual();
}
\font {normal_large}
\width {200}
\height {50}
\BGColor {darkGreen}
\FGColor {white}
\BDColor {black}
\
-----------------------------
To implement the chess board interface, you'd *basically* write a
mini viola application that consists of: objects for representing
board-cells, chess pieces; an object doing the talking with the chess
server; a clock object; text fields for IRC type communications...
The ViolaWWW browser could fetch this chess-board-application
(embedded in HTML or not) from a WWW server, and renders it on the fly.
Now, what I've just described is, I think, more of GUI than Graphics
of a "network graphics language". But the class hierarchy could be
expanded, and grown, to include other classes of rendering objects.
The language syntax could be more abbreviated to make program size
smaller. The viola objects abstraction could be raised to improve
cross platform portability. Viola could be ported to other platforms.
Security could be better improved without giving up too much flexibility
(currently every object has a security tagging, and all objects
instantiated from foreign sources are marked as untrusted to system
priviledges...). etc.
-Pei
Pei Y. Wei ([email protected])
O'Reilly & Associates, Inc.
PS. you might want to forward this to the original To:list. My machine
ran out of machine id spots, it said.