-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Now for the third installment in our groundbreaking series on where to go
the VOS UI :-)
One difficulty I've been mulling over for a while is the fact that while
VOS is focused on providing a unified view of the world which is
consistent across each user, but this behavior is actually undesirable in
certain circumstances. For example, a status or heads-up display or other
transient GUI components are going to be different for each user, and thus
have no place as part of the general world display.
Then today it clicked -- the right thing to do is turn the browser into a
Vobject just like any other. The browser would its own vobject type,
child links and API to control what it displays.
This means that a remote site can now directly talk to the browser to
affect what is on the screen. For example, we could introduce a child
object "browser:overlay". This would be like a sector containing a3dl
objects (or possibly 2D drawing objects) which would be rendered on top of
the normal world scene. Popup windows, inventories, and status
information from the server all could be sent to the browser using this
mechanism, simply by linking them as an "overlay" child.
Action events are now quite straightforward: the "from" field becomes the
browser window, because that's where it actually came from.
A pointer event, such as a mouse click, can interact with the overlay
using the same system described in my previous mail -- so with a few 2D
drawing primitives, it should be easy to construct basic GUI components.
We might also bring back the VOSGUI toolkit.
Going further, I think that it would be beneficial to step one level down
and start thinking in terms of display lists and canvases. The VOS child
list seems like a good fit to store a list of 2D vector drawing commands.
Something similar to SVG in VOS, perhaps? (I see Reed has already started
thinking about this:
http://interreality.org/cgi-bin/moinwiki/moin.cgi/MetaobjectsFor2dGraphics)
Here's the web analogy: the current "cutting edge" is AJAX applications
(okay, it's been around a while, but still). These act by using bits of
javascript to modify the browser's view, typically by fetching fragments
of HTML from the server and inserting them into the browser's Document
Object Model (DOM).
In VOS, the browser would be a Vobject with a full vobject structure
hanging off of it describing what it currently displays. Changing
properties in the vobject structure changes the view -- just like editing
the DOM changes what is displayed in the web browser. However, because
VOS is built on the ability to push, the server is constantly sending
updates to the client browser to reflect changing conditions.
As with my proposal for input, we start with a "dumb terminal" approach.
However, later on we introduce client-scripting, and these scripts can
perform more complex operations with less overhead of talking to the
server. Ideally, this would be quite transparent, involving a relatively
simple migration of functionality from server to client, allowing the
application to not care whether updating the browser GUI is being handled
mostly by the client or by the server.
I think this is a compelling direction to go in. It avoids (for now) the
complexity of client-side scripting, but retains most of the flexibility.
Once the groundwork is laid out, it should be possible to immediately
start experimenting with 3D GUIs and creating (server-based) interactive
worlds. Very exciting! :-)
Comments?
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDnSAPaeHUyhjCHfcRAtxuAJ91yoNvfQpLsOi85hwPc1oqZyEmWACfV2Bq
pIB0btu3UwNtWOS2fXaa9Eo=
=a/tx
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d