I've been quiet, but that doesn't mean I haven't been thinking about VOS development. I'll try to describe some of the things I've been working on recently.
Most importantly, starting July 9th, I will be devoting half of my time (2-3 full days each week) to VOS development. Coding, which has been stalled for awhile, will resume at that point. In the mean time, I have been fleshing out various s5 design details in my mind. The main subjects have been: - Scalability, clustering and recovery from failure. The general ideas is to use replication for load balancing and distributed locks for consistancy control. - Programming with continuations as a way of supporting concurrency without requiring threads. Also how to emulate continuations in languages that don't support them! - Authorization-based access control using object capabilities. I am still planning to write an email discussing capability security in VOS. - User interface for the 3D client. This is a critical issue on which we have spent too little time in the past. Let me talk a little bit about the last part. This time around, I'm going to try and have a prototype 3D client in place even before we've finished writing the core. That way, we have (hopefully) something people can play with while development of the underlying network object model proceeds. I've spent a little while thinking about the interaction mode of the client, and came up with a few basic principals to follow: * It must be very open-ended. The goal is for the application to be able to configure itself to different task, be it a 3D game, social space or business purpose. * It should be usable by both novices who want a minimal browsing experience, and experts who are engaged in scene editing or development. * It should be designed to permit plugins or extensions to its functionality. The model we have been using up until now has been the web browser, but it occurred to me that although familiar, this may not be the right model. Now, what is a highly popular application that is suitable for both viewing and editing, and is open ended... I think the right model is Emacs! I've put together a mockup screenshot here: http://interreality.org/~tetron/terangreal%20mockup.png At the top, like a web browser, you have the current URL (a vobject) which you are interacting with. In the upper right corner, you have the "major mode" which defines how what type of interface to use to present the vobject. For a 3D scene, you might have a "navigation" major mode used for normal browsing and chatting, a "construction" major mode which provided controls for adding objects and moving objects around. If you clicked on a mesh, you could go into an "editing" major mode which allowed for editing polygons and vertices of an individual mesh. If you selected a material, you could go into a "material" mode for editing the material properties. In addition to these specialized modes, you would have generic major modes, such as presenting a hierachical tree view of the vobject structure, or editing text properties. Additional major mode could embed a web browser or other document viewers and editors, operating on resources stored in Vobjects or on the web. Ultimately, the system should be entirely reflexive, so that the user interface is itself described using VOS; this would allow creating both 2D and 3D applications within the platform. The major mode broadly defines how a particular vobject tree is presented to the user and provides a base set of key and mouse bindings. In addition to this, you have minor modes and tools. A "tool" would be a piece of code which can be bound to a key or mouse action. It might operate on the currently selected item, ask the user for input, or just execute some action. The major mode would specify a base set of tool bindings. A tool would be somewhat similar to an Emacs interactive function, in that new tools could be defined on the fly and would operate on the current environment. Tools which only worked with the underlying vobject would also be usable across different major modes, enabling the user to reuse the same commands even with entirely different frontend interfaces. A "minor mode" would be a set of key or mouse bindings that is overlayed on the current major mode. Usually, the user would enter a minor mode by using a tool. For example, the user wishes to grab and rotate a 3D object. The use the "rotation" tool. This invokes a "rotation" minor mode which changes the mouse bindings to allow the user to click and drag to rotate the object in question. When the user is done, the "rotation" minor mode removed and the previous mode is restored. Under this design, a 3D game would supply a minor mode providing a complete set of key bindings to the game controls, such as binding the number keys to "tools" which cast spells. In short, I'm envisioning a sort amalgamation of Firefox, Emacs and Blender, possibly with some Visual Studio-style detachable "pop-out" windows (using wxAUI) thrown in for good measure. It's crazy, but it just might work. -- [ 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 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d