I just wanted to say, these are really good questions and deserve substantial answers and discussion. I'm planning on answering properly when I find the time (a thorough reply will take awhile to compose.)
On Sun, Apr 22, 2007 at 02:18:31PM -0700, Ken Taylor wrote: > So, from a user's perspective, how might the following cases work in an > Interreality 3D system built upon vos s5: > > 1) Someone running a server wants special behavior from an object, written > in the scripting language of their choice, to be attached to an object at > run-time -- but without that code being accessible to clients. > 2) Someone connecting to a server with a client "owns" a bit of 3d space and > can create objects and attach scripts to them. They create a new object with > some sort of behavior, and they upload the script to that object. What if > the script had a syntax error? What if the script tried to do something > illegal or use up too many resources? > 3) Someone wants to write a script for their vos-based client that just > tweaks the interface client-side (perhaps automating some functions or > creating new UI elements). What if they wanted this script to break out of > the typical sandbox? > 4) An object on the server contains a script to be run client-side, perhaps > to perform some special animation effect or to support some custom > interaction with the server, and the user of the client can decide to accept > that script or not. > > Also: will interreality specify any "default languages" to be supported as a > baseline, or will it just be whatever runtimes the current server has > installed? Will there be a way to query the server for what runtimes it > supports, and what capabilities those runtimes have? Can an object (such as > in case 4) have multiple languages attached to it, so the client can pick > which one it supports the best? Can a script specify at the outset what > capabilities it requires so the vos kernel can decide whether or not to even > run it (or to ask the user to allow certain capabilities)? > > -Ken > > ps: Something else that may be interesting -- having a special VOS > translation layer that lets one run scripts wrtten for VRML nodes in a VOS > world. This could facilitate importing VRML files transparently. > > Peter Amstutz wrote: > > Third in a four part series on major design changes in s5 > > (What could also be called "VOS Apocalypse") > > > > Scripting. > > > > One of the things we have encountered over the course of our open source > > efforts was (obvious in retrospect) people don't like dealing with C++. > > While there remain compelling reasons to write the VOS "kernel" in C++, > > for most people the language is hard, setting up a compilation > > environment is difficult, and there are many things a statically > > compiled language simply can't do, such as evaluating new code on the > > fly. > > > > With s3 and s4, we have tried to address scripting using the Simplified > > Wrapper and Interface Generator (SWIG), which is an excelent program > > which can read C and C++ header files and produce bindings into a > > variety of popular programming languages. However, this approach > > suffers from a flaw: by design it is oriented towards calling C/C++ code > > from other languages. It does not, however, provide much support for > > allowing your C/C++ code (or other languages hosting in the same system) > > to call back to that scripting code. So, scripting languages are > > second-class citizens. > > > > What I intend to do in s5 is see to it that all programming languages > > (scripting or otherwise) can be a first-class citizen in VOS, so that C, > > C++, Perl, Python, LISP, Java, C# etc code can all call each other, > > agreeing on the same APIs and data types. The goal, is to allow users > > to write behaviors and extensions for VOS in their programming language > > of choice. > > > > This is, in some ways, one of the holy grails of computing. How many > > times has a project been rewritten, or required redundant work, because > > software A in one language needed to link with software B in another? > > Now, I don't want to overstate what we're doing, but I do believe that > > certain key aspects of VOS enable us to produce a cleaner solution than > > the existing state of the art. > > > > There are three key design elements: > > > > 1. Actor model for Vobjects and message passing. > > > > This is shakes out from the concurrency design discussed earlier. > > Because Vobjects are required to communicate via message passing, it is > > easy to add a translation step that converts message parameters from one > > language datatypes to another. Datatypes will consists of either > > copyable primitives, or Vobjects, so object references that are > > communicated between languages are independent identifiers not tied to > > particular memory (or network) location. Capabilities can be used to > > enforce security between runtimes (more on that later). Finally, and > > most importantly, there is no inversion of control inherent when calling > > on a vobject that is handled by another language. This means that the > > act of calling from one language to another does not result in the > > caller's thread being taken over to run the target scripting language > > runtime or virtual machine, thus avoiding various unintended side > > effects. > > > > If a scripting language runtime or virtual machine is not threadsafe, it > > can be made to run in a separate, private thread and require that all > > inbound messages be placed in its message queue. Also useful is in the > > case that VOS is be incorporated into an existing application or > > framework, all that is required is that the application's main event > > loop be able to periodically check for new incoming VOS events. > > > > > > 2. Object Type Definitions (OTDs) for Interfaces > > > > Object type definitions describe the messages a vobject accepts and > > emits, and the child vobjects it might link to. It is similar in spirit > > to an XML schema or a CORBA interface file, but merges ideas from both. > > It is independent of programming language, and I am working towards > > defining the OTD in itself. > > > > The primary use of the OTD is input into a code generator that produces > > concrete classes that implement the marshaling of method parameters into > > messages, and from messages back to method parameters. Since messages > > are language-neutral, they can now be passed to a handler written in any > > other language. For each supported language, we will have either a code > > generator that produces the required classes, or for more dynamic > > languages, a module with that uses reflection and evaluation to generate > > the required classes. > > > > The advantage of this is that interfaces can be added to any language > > runtime at any time without having to modify either the other languages > > or the C++ kernel. The only essential interface to the C++ kernel will > > be a minimal C interface designed specifically for the FFI (foreign > > function interface) feature present used by many languages. This allows > > most (or all) of the work to be done in the target language that the > > user is most comfortable in. > > > > > > 3. Runtime extensible object model and reflection > > > > Vobjects arn't set in stone. You are free to attach new types, new > > behaviors and new children onto existing vobjects at any time. This is > > extremely useful for situations where you need to take several behaviors > > and smoosh them together into a single vobject (very, very common in VOS > > -- for example a typical avatar has at minimum types misc:avatar, > > a3dl:object3d.model, a3dl:actor and misc:talkative) which could now in > > s5 be potentially implemented is multiple languages. This "mashup" > > capability is very powerful and fairly unique to VOS (I think you could > > probably do it in Croquet due to its Smalltalk basis, but that's about > > it). > > > > This flexibilily also means applications are free to attach > > application-specific data to vobjects that will be ignored by tools that > > don't recognize it. For example, a file format loader for some 3D scene > > could package up the parts it doesn't understand and include them along > > with the parts that have been converted to standard A3DL data. When > > exporting that same scene back to the original file format, those parts > > can be retrieved and output again to yield the identical original file, > > rather than those parts having been stripped off and lost in the > > original loading. > > > > VOS also provides reflection (OTDs will themselves be represented in the > > system as vobjects, essentially metaclasses). For example, iterating > > over child vobjects is very similar to iterating over the fields of a > > class. Vobject structures can be navigated and manipulated using > > generic tools, and scripts which process Vobjects can be simpler and > > require fewer assumptions about the underlying objects. > > > > > > The big picture of what I'm trying to do with s5 is make VOS an > > object-oriented programming infrastructure that ties together all of > > computing, and happens to makes the end goal of an immersive, > > collaborative 3D world really easy to implement. The reason is that I > > want to be able to leverage other people's work in programming > > languages, operating systems, databases and graphics in a way that is > > easy and effective. This is the basic motivation for defining VOS as a > > platform: so in the long run, we don't have to do all the work. So > > instead of stitching together a half-assed 3D engine, a half-assed > > database and a half-assed scripting language all created in-house, we > > can create a best-of-breed system that ties together the best of each > > category. > > > > > _______________________________________________ > vos-d mailing list > [email protected] > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ 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 [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
