Re: [vos-d] s5 scripting (design part 3)
Ok, finally have some time to address this :-) 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. By code not accessable to clients do you just mean that clients can't see the source, or that in fact other users arn't able to run it, they don't have the execute bit set, in Unix terms? Let's answer both. My current design calls for behaviors to be implemented with VOS metaobject types. A vobject type will effectively be a class, and message handlers are methods. To add a behavior, you define a new type and connect your script to the message handlers for that type. I intend to expose the type system as part of the VOS structure, so you might go to /types/mygame/monsters/orc to define the behaviors specific to orc (which would inherit from the monsters type and be part of the mygame namespace). Thus, normal vobject security can be used to enforce who can and cannot view and/or change the scripts. The second question is that once you've defined your script, how do you restrict it's use to only the objects you authorize? In this case, we can still use the security system, but we either a) have the add type command check to see if you're allowed to add it or b) adding a type to a vobject means you ask the type vobject to bless your object with its behavior. In (b), you can restrict who can use that type by restricting who has has access to your bless method. 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? This is actually three questions. 2a) If the script has a syntax error, it needs to be reported to the client. I think the best strategy will be to enforce that the scriptable metaobject type only accept syntatically correct scripts, so if you upload a script with an error, you get back a polite error message telling you what was wrong. 2b) If the script does something obviously illegal, it should be terminated with extreme prejudice. I'm not sure where the error should be reported, although the user should have some indication that what their script was terminated. That said,, my idea for s5 security is to use a capability system (which I haven't talked about yet, but I'm working on it) which actually makes illegal actions impossible by design. 2c) Imposing resource limitations is really tough. There are basically three resources that matter: CPU, RAM and disk space. In a persistant system that can swap out objects, we can more or less claim that RAM == disk space and main memory is a fast cache. That leaves us with RAM and CPU. RAM quotas can be enforced by tracking memory allocation/freeing requests and having those requests rejected when some limit is exceeded. Similarly, the virtual machine running scripts will need some way of tracking how much CPU time has been used. From a computational standpoint, is pretty close to the scheduling problem faced by operating system designers. The VM needs to provide a way of preempting a process when it goes over, or some sort of enforced yield that compels the process to check in and yield at key points in execution. To do both of these things properly will require some degree of control over the virtual machine that is running the script. This is to be expected, mobile code is really hard and has not been well addressed by current programming languages and virtual machines. Java and Javascript have mediocre security models that have been considered good enough but don't really address obvious problems like a rogue scripts that try to use as much CPU and RAM as possible. A lot of this also borders on essentially operating system tasks (I have been pondering that VOS bears many similarities to classic microkernel design for OSs) so it might also make sense to think about ways the underlying OS can be used to sandbox untrusted user scripts. 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? The UI will need to be built from vobjects, and the script would add or remove vobjects representing that user interface elements to provide controls which ran your scripts when activated. In terms of security, changing user interface elements is one of the primary tasks that scripts will be
Re: [vos-d] s5 scripting (design part 3)
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
Re: [vos-d] s5 scripting (design part 3)
As an illustration of this, I'd like to remind folks that there is a prototype of s5 with almost-usable python scripting in my s5.scripting branch. There are some kinks to be solved about messages that return multiple values (I need to clarify how this works with Peter on IRC some day), and creating vobjects is currently cumbersome (because Peter intends to make this operation reflexible too, so when it is, that's what Python will use), but you can already run simple tests with is and see what it's going to look like. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 scripting (design part 3)
There are branches of s5 available? How do we get to them? -Ken - Original Message - From: Lalo Martins [EMAIL PROTECTED] To: vos-d@interreality.org Sent: Saturday, April 21, 2007 11:40 PM Subject: Re: [vos-d] s5 scripting (design part 3) As an illustration of this, I'd like to remind folks that there is a prototype of s5 with almost-usable python scripting in my s5.scripting branch. There are some kinks to be solved about messages that return multiple values (I need to clarify how this works with Peter on IRC some day), and creating vobjects is currently cumbersome (because Peter intends to make this operation reflexible too, so when it is, that's what Python will use), but you can already run simple tests with is and see what it's going to look like. best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. - personal:http://lalo.hystericalraisins.net/ technical:http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
