Good evening everyone. I realize the mailing list has been extremely quite for several months, and combined with the approximately two weeks of downtime we experienced with interreality.org,one might be excused for thinking that VOS was dead. I am happy to say that this is not the case. However, a metaphore for the current project might be that it is currently cocooned, and undergoing a metamorphasis.
Specifically, I am currently engaged in a significant rewrite of the core runtime infrastructure, libvos. I want to talk a little bit about the reasoning behind this, what there will be look forward to in the new core runtime, and what the project plans are for the medium term. 1. Although light years ahead of the VOS implementation it replaced ("s3"), the current implementation (known as "s4") has started to encounter its own architechtural limitations and design flaws. Some of the major issues we've encountered are: * confusing threading design whereby event callbacks are executed by arbitrary threads, placing a significant burden on the application developer * large memory footprint per vobject, sharply limiting the ability to create very large numbers of vobjects * no provisions for offline persistant caching * difficulty in designing scripting hooks that allow scripts to be on the same footing as native C++ code * identification of sites based on hostnames and/or IP addresses, leading to numerous problems with name aliasing and confusion After giving these issues a great deal of thought, my conclusion was that these are ultimately fatal flaws in the design of the current implementation. The best course of action was to start over from scratch, taking the knowledge gained from the previous attempts to craft a new core infrastructure that would be a giant leap forward in functionality. It is very very important to note thatt none of these implementationn problems invalidate the core Vobject model! It is still by firm belief that the basic, fundamental abstraction of message-sending actors with lists of links to other objects is the right one. In that light, this redesign is not so much a radical change, as simply a refinement of the core ideas in light of further experience. 2. The goals of the new design are to provide robust solutions to the major problems outlined above, while maintaining the basic features of VOS that have made it successful. Probably the greatest motivation for a new design was the desire to incorporate the ability to extend the system dynamically via scripting languages. This presented a couple of problems: one problem was simply the inherent complexity of binding C++ interfaces into a target scripting languge. The second was the a more philosophical problem. How do you decide what thread of control is responsible for handling a message? When you start dealing with not just C++ code but other language runtime systems, it is no longer clear that simply executing a callback in whatever thread is convenient is desirable. For the first problem, the solution was relatively straightforward. The new libvos will offer a stripped down C API that is designed to be easy to bind to scripting languages. Furthermore, the method interface to a Vobject type will now be specified in XML and wrapper/framework classes generated from the interface definition. By writing a new module to the code generator, it will be straightforward to add support new languages. For the second problem, the decision was to introduce a new restriction to the abstract Vobject model: an individual vobject now represents a single, independent thread of control. A particular vobject is now only allowed to process a single message at a time. Many vobjects may be executing simultaneously, but the model now states that a single specific vobject is only allowed a single thread of control. Some of the other work includes ensuring that the actual vobject classes are designed with memory footprint in mind (something that was not part of the "just make it work" attitude of aspects of the s4 implementation.) The application is now no longer permitted to have direct pointers to the Vobject objects, but rather works through vobject id handles. This makes it easier to shadow, swap and cache vobjects in the background, because it is no longer possible to invalidate a pointer held by an application. Finally, sites will be uniquely identified using 128-bit public keys (using eliptic curve cryptography). The connection process will include a challenge/response protocol to verify that a site owns the corresponding private key to go with its public identity. 3. This is going to take a while. I don't have nearly as many hours in the week to dedicate to VOS as I would like, but I work on it when I can. This is a major undertaking with a lot of pieces. I have most of the design in mind already, it is mainly an issue of finding the time to grind through writing/testing/debugging the actual code. (And of course, paper or mental designs have a way of running into all sorts of implementation issues when trying to express them in real code.) Fortunately, one initiative I have taken with this new codebase is to build it from scratch using unit tests. This will give a baseline assurance of code quality, which will hopefully reduce the time spent debugging in the long run. My present plan is to make one more release based on the s4 codebase, this will be 0.24. There are some important fixes and improvements in the development version that should be rolled out into an official release. I don't yet have an estimated date for 0.24. My goal is to first bring the s5 development branch to a state where it represents a minimal VOS implementation under the new design, then go ahead and switch gears to work on polishing up 0.24 for release. 4. It is probably fair to say that the history of VOS development has been characterized by the design, redesign and constant tinkering with the runtime, and as a result the full potential of the end-user applications (particularly the 3D world browser Ter'Angreal) has suffered for lack of attention. On the other hand, nearly all of these work has been directly motivated by challenges that have come up in the design and implementation of the 3D client and 3D world server. At the end of the day, fundamentally we are trying to solve a very complex problem. Complex problems require complex solutions. - Pete [ 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