Re: [vos-d] Project: Zephan
Congratulations! On Wed, Jul 30, 2008 at 11:51:27AM -0400, Reed Hedges wrote: I have a new top priority project that must compete with VOS -- Zephan Isaac was born on Friday at 7:30 PM! Though so far he's been great and we're well rested (so far) and on top of the world. More photos and news will be on my web site and on flickr in the upcoming weeks. Reed -- http://interreality.org/~reed ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] getting back on track
I just wanted to mention that I have recently started taking the train to work instead of driving. This gives me about 45 minutes each way of reliable, uninterrupted time to do a bit of hacking, so I will finally be able to get back on track working on VOS after a couple months of coding drought. Since my laptop is a MacBook Pro, the first order of business will probably be to get the voss5 branch to work on OS X. The commuter rail also offers a 802.11 to cellular bridge so I even have Internet access! There are still some outstanding design issues I am mulling over, once I have resolved the immediate issues with my development environment, we'll have to restart the conversation on design and strategy. [ 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 ] ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 properties again
On Sat, May 03, 2008 at 09:00:30AM +, Lalo Martins wrote: For me this kills it. How much do you estimate it would set you back? And is what's wrong with the current design serious enough to justify this time? A good yardstick for that is: is the new design sufficiently better that, if you stop now to implement it, you'll still have gone as far by end of this year as you would if you don't? I know, that's why I wanted to get input from everyone first. The original reason I even got on this track was that in the process of designing serialization and marshaling for getters and setters, I realized the old tentative design created a number of problems I couldn't resolve, which caused development to hit a brick wall. I actually have a long email I wrote last week outlining the problems in great detail, I didn't send it then but I will do so now. *IF* you really think it's worth it, then I'm willing to discuss the details; but I think before we even get to that, it would be good to discuss whether a project of this magnitude is worth considering at all. Well, at the moment I'm in a bind one way or the other, since I can't proceed without resolving this impass. -- [ 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
[vos-d] s5 properties proposal
Why the current s5 design for embedde children doesn't work... Background. A key aspect of the design of VOS s3 and s4 is the parent/child list. This is an associative array of name/value pairs, where the value is a link to another vobject. This list of outgoing links plays a key role in VOS as the primary mechanism of linking vobjects to properties (other vobjects storing values that describe the first vobject) as well as the overall organization of vobjects into a (mostly) hierarchical namespace. Advantages of this scheme (that have gotten us pretty far): - A naive implementation is very easy, only need the Vobject class. - Serialization/persistance is pretty easy. - Introspection of the vobject structure is straightforward. - Accomodates lists (order-sensitive) and maps (key/value pairs). - Vobjects can share properties and link to remote properties. Disadvantages of this scheme (that we learned the hard way): - An efficient implementation is very difficult. Since properties are standalone vobjects, there is a great deal of overhead associated with it: the property vobject has its own child list, access control list, listener list, etc. - Because of the overhead, scaling up to large numbers of vobjects (over 10,000) turned out to be a problem. - The child list is always order sensitive, even when not required or desiriable. - Poorly suited to object/relational mapping. - Associative array semantics permits duplicate, redundant or conflicting entries; whether that causes problems depends on how the child list is interpreted. - Difficult to deal with the case where one property is dependent or constrained by another property without exposing a race condition or requiring additional concurrency semantics. Original proposed solution. Originally, the solution was to keep the basic associative array child list, but introduce embedded children: child properties which are actually stored and managed by the vobject that owns them. These would appear in the child list as normal vobjects, could be individually linked to and/or replaced by links to remote vobjects. When doing serialization or persistance, embedded children would be treated specially and stored efficiently. Advantages: - Retains the advantages of the s3/s4 child list. - Much less (storage) overhead than s3/s4 approach. Disadvantages: - Implementation is hairy. Parent vobject must juggle a bunch of pseudo-vobjects. - Embedded children still have some per-vobject overhead in the form of special entries in the child list. - Leaky abstraction. Embedded children appear to be vobjects, but most vobject operations (such as having a child list itself) won't be available. - In order to save efficiently, serialization/persistance code must be able to distinguish between embedded and non-embedded children, which defeats the purpose of presenting a unified interface. See the thread s5 properties again for discussion for a new design that avoids these disadvantages. -- [ 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
[vos-d] s5 properties again
Some ideas for a new design for properties. Replace the vobject child list with a property map. A property is a slot that holds some value, which can be a basic type (int, string), a compound type (struct, array or map) or a reference to another vobject. Reflection permits iterating over all entries in the property map. Unlike links in the child list, the order of properties is not significant, and two properties of the same name are not allowed. Where order is important, data can be stored in an array property. Paths are still available. For example: /vos/Namespaces/core/Types/String Where vos is a vobject Namespaces is a map of names to vobject references core is a reference to a particular vobject Classes is another map, part of core String is a reference to another vobject Another example: /scene/objects/_2/position/x Where scene is a vobject objects is a list of vobject references _2 is the reference at index 2 in the list position is an xyz vector struct x is the x member of the struct At any point you can get a directory of properties underneath some path, along with a reference to the VOS type. /scene/objects/_2/position/* would yield x (/vos/Namespaces/core/Types/Float) y (/vos/Namespaces/core/Types/Float) z (/vos/Namespaces/core/Types/Float) /scene/objects/_2/* would yield position(/vos/Namespaces/a3dl/Vector3) orientation (/vos/Namespaces/a3dl/Vector4) color (/vos/Namespaces/a3dl/Color) And so forth. Properties would be referenced using a vobject id + path. Properties would be manipulated (get/set methods) by sending messages to the parent vobject and including the path to the property of interest. Vobjects subscribe to property changes by providing the path referring to the property of interest. Reflection would hold additional metadata describing properties, such as which properties should be automatically stored for serialization and persistance. Vobject references would support both hard links (link to a specific vobject id) and soft links (where there is a relative path that must be resolved to determine the actual vobject). In addition to embedded properties (those which are part of the state, which are always there) the user would be able to attach their own override properties. An override property would be either an entirely new property, or replace an existing embedded property. Matching an override would be path based, for example: addOverride(/object/position/x, 22) Would change the x component of the position to 22. Any read or write to x or position would use the override, rather than the underlying value. Removing the override would restore the old value. The override could provide a slot to store the value, it could tie the get/set operations to some other property of the same type (referenced as a vobject + path), or it could tie the get/set operations to some other methods a vobject. Advantages of this approach: - This makes the vobject model is much closer to the most common idea of objects as methods + properties. - A purely dynamic implementation is easy using maps and lists. - A static implementation (where the underlying properties are zero-memory-overhead) is straightforward using code generation. - Serialization, peristance, synchronization and replication are easier since purely declarative data (state) is distinct from the imperative methods that manipulate it. Disadvantages: - It isn't VOS since it discards the last trappings of the s4 vobject model - It's going back to the drawing board (again) (not completely, but it does mean some work redesigning the VOS APIs, the XOD format, changing the code generator, etc) Thoughts? -- [ 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
Re: [vos-d] s5 vobject properties
be either embedded properties or dynamic properties, but since it would be a map there wouldn't be any ordering issues. Ordered lists (necessary for applications like hypervos) would still be possible, but would stored as properties (so you would have a property would be a list of outgoing links.) In this scheme one could share the same value among multiple properties could be acomplished by overriding the embedded property with a dynamic property linking to the shared value. This idea is still a little half baked, so I will follow up with examples when I have nailed the design down a bit more. [ 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
Re: [vos-d] More new S5 classes/concepts
On Mon, Mar 03, 2008 at 05:27:46PM -0500, Reed Hedges wrote: I was under the impression that, for the most part, you are always going to be working through Wrapper objects. Is this true? The ultimate purpose of the wrappers is support marshaling for cross-language and cross-host method calls. Since C++ doesn't have a built in interception facility, you have to insert some stub code in between the caller and the target. One way to do this would be remote objects like we had in s4, but that doesn't handle the cross-language/cross-thread cases very well. Instead, s5 has very lightweight wrappers which manage access to the underlying object. So yes, in normal code you almost always want to be working through the wrapper classes, since they make everything else work (marshaling, reference counting, promises). I'm willing to entertain naming schemes other than -Wrapper, I just don't want it to be the stem name for the simple reason that due to the semantics of C++ it would be ambigious whether you are working with a smart pointer or a copy of the actual object. Possible alternatives: VobjectWrapper VobjectHandle VobjectStub VobjectPtr VobjectRef -- [ 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
[vos-d] serialization
My current task is working on a serialization framework for structs and Vobjects. This will handle loading and saving state for vobjects, and provide the basis on which to implement marshaling and persistance. Being able to load and save structs will also make it possible to start working on some of the upper layers of the VOS stack, such as A3DL (which needs to be able to efficiently represent data like vertex arrays.) I have worked out an efficient template-based approach which supports arbitrary serialization/deserialization methods, so we can easily have binary, XML, YAML, JSON etc serializers, and message encoding for VOS network protocols will probably be built on the serialization framework as well. -- [ 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
Re: [vos-d] templates/macros
I went ahead and did it already, actually. I needed the template functionality in the core so that I could specify VOS classes that are logically templates, such as UInt8DynamicArrayProperty (which is a property holding an array of bytes). Without a template feature, I would have to do a lot of cut and paste to get DynamicStringArrayProperty, DynamicVector3ArrayProperty, etc... The current scheme is somewhat incomplete though, we will need listeners to be able to properly propagate changes in the base template to all the template instances. On Sat, Mar 01, 2008 at 02:14:00PM -0500, Reed Hedges wrote: Peter Amstutz wrote: The idea is to set up Template vobjects which have TemplateParameters which are stand-ins for links other objects and are substituted when you actually create a template instance. The TemplateInstance vobject links to the template and some set of parameters, and will have an instantiate method on it which produces a vobject structure with the appropriate parameter substitution. This is definitely something we need. It ought to be very straightforward to implement as a component type, using listeners. But let's not add any more tasks like this right now, let's get the VOS core working first (including listeners) Reed ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Website design ideas
Wow. Very impressed. Reminds me how much web design is really not my thing. I would say I like the color/styling/background of #1 but the more column-oriented layout of #2. On Sun, Feb 17, 2008 at 08:06:50PM -0500, Reed Hedges wrote: Here are two ideas I had for a new website design. Both are rough sketches. 1. http://interreality.org/~reed/tmp/iro/index.html 2. http://interreality.org/~reed/tmp/iro/index2.html Thoughts, ideas? Reed ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] templates/macros
Here's a quick brain dump of something I'm working on. The specific goal is deal with the problem of parameterized types. In this example, I show how one might define UInt8DynamicArrayProperty as a Property holding a DynamicArray of UInt8. The idea is to set up Template vobjects which have TemplateParameters which are stand-ins for links other objects and are substituted when you actually create a template instance. The TemplateInstance vobject links to the template and some set of parameters, and will have an instantiate method on it which produces a vobject structure with the appropriate parameter substitution. Nothing coded yet, so this will likely change. Incidentally, this is actually fairly similar to the template system coded for the original hypervos (which runs parts of interreality.org) so this idea of generalized subtree substitution is likely to be useful beyond the specific problem I'm trying to solve. vobject name=Property type=/vos/core/Template vobject name=produces linkTo=/vos/core/Class / vobject name=propertyType type=/vos/core/TemplateParameter / child name=extends type=/vos/core/Component / vobject name=value type=/vos/core/Member child name=param linkTo=../../propertyType / /vobject /vobject vobject name=DynamicArrayProperty type=/vos/core/Template child name=extendsTemplate linkTo=/vos/core/Property / vobject name=memberType type=/vos/core/TemplateParameter / vobject name=propertyType type=/vos/core/DynamicArray child name=memberType linkTo=../../memberType / /vobject vobject name=size type=/vos/core/Member child name=type linkTo=/vos/core/UInt32 / property name=readOnly type=/vos/core/BooleanPropertytrue/property /vobject vobject name=getSlice type=/vos/core/Method vobject name=formalParameters type=/vos/core/Struct vobject name=start type=/vos/core/Member child name=type linkTo=/vos/core/UInt32 / /vobject vobject name=length type=/vos/core/Member child name=type linkTo=/vos/core/UInt32 / /vobject /vobject child name=returnType linkTo=../../../propertyType / /vobject /vobject vobject name=UInt8Property type=/vos/core/TemplateInstance child name=template linkTo=/vos/core/Property / child name=propertyType linkTo=/vos/core/UInt8 / /vobject vobject name=UInt8DynamicArrayProperty type=/vos/core/TemplateInstance child name=template linkTo=/vos/core/DynamicArrayProperty / child name=memberType linkTo=/vos/core/UInt8 / /vobject -- [ 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
Re: [vos-d] s5 site ids
You've got it. Setting up aliases based on prefix at the top of the XOD file was exactly the solution I had in mind to the verbose-site-ids problem. Similarly in the code generator we just need to emit a macro which hides the scary site namespace. On Tue, Feb 12, 2008 at 06:04:50PM -0500, Reed Hedges wrote: In VOS it in fact would be easy to build a little tree of the types with different names to make them easier for people to work with, while keeping their real names hidden. So you can make an object like /t and select out the specific top level versions used from the containers (namespaces?) with the big ids. E.g. /t/vos - /vos:0011223344556677889900aabbccddee/vos ...Has various children for core types... /t/a3dl - /vos:0011223344556677889900aabbccddef/a3dl ...Has various children for 3d types... /t/mytypes - /vos:992288337744beffc38aa3712cdd219a8e/mytypes ...Has various children for custom types... /foo type=/t/mytypes/foo /bar type=/t/a3dl/object3d Maybe we even enshrine a container like /t or /_types as standard place to put the working set of types, as a convention that all user interfaces use, and so when they are telling a user what the type of a vobject is, they can just strip off the prefix, or when preseting the user with a list of possible types, just provide a listing (or tree view) of the children of /t, etc. Or a UI can just look at the type definition to get a user friendly type name. But OK, in the general case, we need to come up with ways like this to help users navigate vobjects, whether in a particular application or in VOS stuff like this, without having to put a lot of special stuff in the user interface clients. Reed -- [ 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
Re: [vos-d] s5 site ids
On Sat, Feb 09, 2008 at 01:02:15AM +, Lalo Martins wrote: Yet, you didn't address my actual point ;-) I know what site IDs are supposed to be for. My question is -- do we really want libraries to ship as a separate site each? I realise the key space is pretty large, so polluting it is probably no big deal, but I see no big advantage in this case. (You would need to ship the private key, anyway, right?) In VOS terms, a Library is a set of interfaces, not concrete classes. This is why the Implementation objects are separate from the Class objects. This idea needs to be developed more, though, since even within the VOS type system itself I have found it useful to have both abstract classes (that cannot be instantiated ever, interface only) and concrete classes. With regard to shipping the private key, my thinking is that publishing an API is like specifying a protocol, and that you really want a way of unambigiously referring to a specific API as published by a specific entity at a specific version. If you let everybody have the private key then you cannot guarantee that, because anyone could produce a signed API document. One of the foundation concepts in s5 is that ownership of a private key implies the ability (and responsibility) to coordinate changes to that site so that you don't have conflicting replicas floating around from different sources. -- [ 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
Re: [vos-d] s5 site ids
On Fri, Feb 08, 2008 at 09:52:40AM +, Lalo Martins wrote: Is there any rhyme or reason to site ids? The current testing site ids are not true site ids. The site id is actually supposed to be the public half of a public/private key pair using elliptic curve cryptography. A 128 bit key yields about 64 bits of security. If all libraries will ship a separate site (as XOD or something) with their OTDs, won't that pollute the site id space? And aren't them bound to clash at some point? Maybe set up a registry of library site ids somewhere in the website? The idea is for site ids to be globally unique, since there is only a 1/2^128 chance of generating a collision. In order to claim to be a site you have to prove that you know the corresponding private key, thus you can't just pick an aribtrary public site id (unless you know how to work backwards to get the private key, in which case the NSA would like to have a word with you.) Or is this (library OTD) going to be substantially different later on? I understand your confusion, it isn't very meaningful at the moment because it is not yet doing any of the digital signature checking that I have planned. I need to write a tool that spits out public/private keypairs for use with VOS. -- [ 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
Re: [vos-d] More new S5 classes/concepts
On Mon, Jan 28, 2008 at 03:28:57PM +, Lalo Martins wrote: Also spracht Peter Amstutz (Sun, 27 Jan 2008 23:38:04 -0500): (lots of clarifications on s5 concepts/classes) On that note... can we have a documenting property (akin to Python's docstrings and __doc__)? Preferably with nice syntax sugar on XOD :-) Just having all the information you have on this post, right there on the XOD file (and presumably the C++ generated from it) would have helped immensely. There's a description property which is pretty much what you're asking for, it can be attached to most elements (classes, methods, members, etc) and is intended to be used for output to code comments and to code documentation tools. With regards to syntactic sugar, the current XOD format is intended to be very low level data structure dump. What I would like to do is use XSLT or a macro language to define translations from a friendlier syntax (which can include all sort of helpful tags) to a low level representation such as XOD. Also... I can't make heads or tails of interreality3d :-( could we have a very minimal hello world? Ask and ye shall receive. Take a look at voss5/src/app/helloworld. -- [ 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
Re: [vos-d] More new S5 classes/concepts
context. In the interreality3d app, the TreeView can view any VOS data type (since displays the vobject children) and requires a wxWindowContext. It creates a view object which then actually adds the necessary wxWidgets controls to the supplied wxWindow to display the tree view. What does it mean to append children to the local host? I am guessing this is so the object doesn't get destroyed (by reference count/garbage collection), and so you can also obtain it by name later? Do all The local host is a special site. Sites now have a root child list which is like a root directory. objects need to be added to the local host (like they were all children of the local site in s4)? And if so, why not do that automatically when created? When created, vobjects must be associated with some site (such as the local host). The intention is that in order for the vobject to be persistant, it must be connected to the vobject structure so there is a path from the root to the vobject. Vobjects which are not connected to the root are not persistent. Can you explain more these changes to A3DL? What is a scene, what is a render layer, clock, node, etc.? I'm in the process of redesigning A3DL based on my experience with several mature scene graph APIs (Gamebryo, Open Scene Graph and Lightfeather.) The new A3DL design is pretty preliminary and not actually implemented at all. I'll go over it when I've actually put a bit more work into it and there is some code that actually does something. -- [ 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
Re: [vos-d] MVC
Lalo and I talked about this briefly on IRC. In think the central idea is simply to have a repository (the factory in the document) where you can go and say, I would like to view this object X, with display type Y and get back a list of possible candidate vobject implementations that can view or control the model vobject. The view type or display type could be a text terminal, 2D GUI, 3D environment, web page, etc. This is a generalized notion of some of the ideas I was exploring in the Interreality 3D prototype, with Lalo's interest in specifically applying it to web apps. Personally I think this makes a lot of sense, and is likely something that should be part of the core APIs. On Mon, Dec 10, 2007 at 10:28:36AM -0500, Reed Hedges wrote: Thanks for writing up your thoughts. How important do you think it is to define specific interfaces for MVC? One thing I started doing for S4 was a library called vos toolbox that as a set of tools, mostly in the form of listener classes and metaobject classes, that can be used to translate events from one group of vobjects into actions applied to another - i.e. they could be used as building blocks in implementing MVC controllers. There are a few checked in to the s4 repository (some that do math or reformat property values), and I have more ideas listed at http://interreality.org/wiki/ApplicationVosToolbox Reed -- [ 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
Re: [vos-d] s5 progress and design
On Thu, Dec 06, 2007 at 11:11:31AM +0100, Karsten Otto wrote: Ok, I see. But this implies there could be more servers than just one, each hosting a replica. Which one do I contact for updates? With VOP/VIP URLs this was straightforward, but please remind me again, how do I contact a vos:0011223344... key-based site? Is there a name server somewhere? There's one additional complication, which is that there are sites and there are hosts. A host is a special kind of site which is never replicated and represents a single process/single instance of a server. The goal being that a site can be clustered across multiple hosts. So a site is bound to one or more hosts, and connections are made between hosts rather than between sites. This provides a layer of abstraction between the concrete concept of a site (an actual OS process on a physical computer) and the virtual concept of a site which is replicated many places. Ownership of a site simply means knowing the private key. If you know the private key, you are able to issue properly signed documents that describe the state of (and state changes to) the site. To answer your question, yes, this requires some way of mapping identifiers to network addresses. My original idea was that the site issues a signed document listing one or more hosts ids that are authorized for that site, and the host issues a signed document listing one or more network addresses it can be contacted at. That contact information is propagated through friend-of-a-friend introductions, so that if some site tells you to contact another site, it can also provide the contact information. Other name resolution methods (DNS/MDNS, distributed hash tables, central metaserver on interreality.org, or ???) would also be a good idea. Unlike DNS, spoofing replies is much more difficult, since the replies have to be signed to coorrespond with the same public id you are trying to resolve. For the separate matter of mapping human-readable names to site ids, I don't have an answer to that. That's sort of a sticky problem because such a system should be hardened against all sorts of abuse (spamming, domain squatters, etc) many of which are social and not technical. I'm imagine there's been some interesting research into this area, though, which would be worth looking in to. Uh, okay... so... The site in this document is just a namespace, which makes sense given the new idea of a site being some abstract thing manifested only by lots of replicas. I.e. when I use the type vos:00112233/OTD/vos/FooClass I am using a replica of the abstract type definition. I was confused since I still though of a site as something you could connect to with Ter'angreal or mesh, while the new kind does not necessarily have any actual servers hosting the replicas. ... Right? You've got it. The idea is to move towards content-oriented addressing rather than location-based addressing, at least at the granularity of a site. Of course, for interactive sessions, you maintain a session to an actual server which is the actual site, so that you can exchange updates in real time (for walking around in a 3D world or whatever). Ok, so the average user will never be concerned with MyTypeImpl, but only ever interacts with MyTypeWrapper? In this case I agree with reed to drop the Wrapper part and just call the thing MyType. The average user is concerned with MyTypeImpl if they are implementing new components, which I would hope to be a common operation (as common as adding new classes to any object oriented application). The user also needs to supply the correct implementation when instantiating a new vobject, since if there are (for example) two implementations of IOutputStream, you need to select which one you actually want. In terms of actually calling methods on it, it is isolated from the user via the wrapper class, for implementation reasons I discussed previously. I'm still mulling it over. It does make the client code easier to read, but at the expense of potentially introducing confusion between the wrapper classes and real classes, which have very very different semantics. -- [ 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
Re: [vos-d] s5 progress and design
on the assumtion that
there are more of them. I.e. if i want to access a remote Java
object, I only need its MyType interface and an remote object
reference. If I want to *create* a new remote object, I have to
design the MyType interface for the users, and create an MyTypeImpl
with the actual functionality. There is a hidden third class, a
MyTypeStub, which is usually autogenerated, and which handles the
marshalling for remote (or local!) invocations - this is what users
handle, though they are never aware of it, only of the fact that they
got a MyType object to use.
So, how is this didfferent from what VOS s5 is supposed to do?
In your example, MyTypeWrapper in VOS is roughly equivalent to the
marshalling stub. The difference is that (and correct me if I am wrong
on this) the semantics of CORBA and Java RMI are that on local objects
method invocations are made directly and executed in the same thread,
and on remote objects method invocations are synchronous, blocking
calls. In VOS, my intention is for all method invocations to be
asynchronous, nonblocking calls, including calls between different
threads in the same process. As a result, *all* objects in the system
need that stub harness, even if the common case (invocations in the same
process, in the same thread) still just pass through to the underlying
concrete implementation.
Because you're calling between threads on a shared memory system, it
doesn't make sense to create heavy remote stubs that are managed by
the framework for objects which already exist in process. Wrappers are
not managed by the framework but are instead lightweight stack objects
that can decide whether to marshal (or not) the method call based on the
circumstances.
My concern is that if the wrapper class is named with just the name
stem, the following situation is very confusing:
{
Vobject* foo = getFoo();
delete foo;
// Oops. I think I deleted foo, but all I did was delete
// the wrapper. The underlying object is actually still there.
}
{
VobjectWrapper* foo;
delete foo;
// I know it is a wrapper, so I know I'm just deleting the wrapper
// and that the underlying object is untouched.
}
This is a little contrived, since wrappers are usually stack-allocated
(although the confusion is still there, just not as obvious), but
similar cases can be made for other common operations such as assignment
and comparison.
It's ugly, but it should be considered an artifact of the
implementation. Languages with better metaprogramming facilities (meta
object protocols, in the traditional academic sense) and hopefully
script language bindings should not require this technique.
--
[ 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
Re: [vos-d] s5 progress and design
On Wed, Dec 05, 2007 at 11:34:45AM -0500, Reed Hedges wrote: We should also include at this point a reminder of why there's a code generator. If I understand things correctly, the goal is to use the code generator to (a) generate code for different programming languages (b) make it easier for users to generate MetaObject (now called Component) wrapper classes corresponding to different type interfaces (and in different programming languages). The fact that Peter happened to use the code generator to generate VOS itself is, again if I understand it correctly, partly for (a), and partly to make sure it works well. Correct me if I'm wrong Pete. You're on the right track, but there's more to it than that. It provides a set of formal semantics for VOS which are defined externally of a particular programming language. With the spec in hand, you only have to write a code generator (or other metaprogramming layer) and run it against the spec to map VOS onto a new target language. It gives a self-contained type system, so when two programming languages talk about a VOS Class, they are unambigously referring to the same thing. It also encourages developing an OS- and language-independent vobject-based standard library of APIs and components instead of dropping down to the language-specific standard library for common tasks. For example, I've already added InputStream and OutputStream classes as part of VOS in order to read and write files. This means you will be able to read from or write to streams which come from other language runtimes, processes, or hosts. In the case of the C++ binding, the code generator will automate marshalling, unmarshalling, and pipling, which would be tedious and error prone to write by hand (and changes often during development). C++ template metaprogramming doesn't really help here, since templates don't provide the reflection features to be able to say for each method in this class... Finally, the code generator also keeps some other miscellaneous boilerplate code in sync, such as registering classes and implementations, and embedded the correct copy of the interface spec in the executable so that reflection is available at runtime. Rather than simply being a convenient tool, the VOS object model is almost a new language that happens to be hosted on C++. I actually hope to see VOS implemented in other languages (and not just through foreign function interfaces) and think it will be a better fit for higher-level languages that already provide garbage collection, reflection, marshaling, promises, continuations, etc. -- [ 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
Re: [vos-d] s/MetaObject/Component
On Thu, Nov 29, 2007 at 01:33:22PM +0100, Karsten Otto wrote: Also metaobject is an existing term of art in the programming language community having to do with defining and manipulating the semantics of how programming language objects are invoked, and while this is something that will exist in VOS, the current MetaObject class isn't it. Ok, I heared that term before, but am not quite sure what it means an certainly don't use it in day-to-day programming (maybe I'm just old- fashioned). http://c2.com/cgi/wiki?MetaObjectProtocol It's not something people use in day-to-day programming (unless your job involves Common Lisp or Smalltalk) but it is an entrenched term in the object-oriented community, so I prefer to avoid the confusion. I understand your desire to avoid a clash of terms, but I don't think Component is a good replacement; in fact it may make things worse! If you absolutely have to rename it, I'd rather see one of the other fuzzy terms like Facet, Aspect, ... Well, Aspect implies (to me) aspect-oriented programming. Facet is a possibility, although I've mainly encountered that in the capability security community where it has a little bit different connotation (as a possibly-restricted view or handle that mediates access to some underlying object). The most common use of term component is probably in the context of COM, XPCOM, KParts and so forth type of systems where it simply implies loosely-coupled objects, with separatation of interface and implementation and often dynamicly loadable and language-neutral. The plan is for S5 VOS vobject MetaObjects to do all those things, hence changing the name to component. On a side note, I have been meaning to sit down and do a writeup on s5 development progress, which will hopefully clarify things a bit. While for several months I was working part time to be able to devote time to VOS, I am presently working full time again for financial reasons, so VOS development is squeezed -- even writing email. -- [ 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
Re: [vos-d] s/MetaObject/Component
Part is even more generic/vague than component, I think. Subparts might be slightly better. Another way to look at it, which would be clearest: vobject-getParts(); vobject-getSubparts(); vobject-getFacets(); vobject-getRoles(); vobject-getTypes(); // very bad, the term type is already overloaded vobject-getFragments(); vobject-getTraits(); vobject-getComponents(); Fragment was another term I was mulling over, although that implies to me something that is broken or incomplete. I still prefer component, since to me implies a nice, well defined piece that is designed to plug into a bigger system. I should also point out that if we were to interface COM with VOS, it would most likely be in the form of mapping VOS (MetaObject) APIs to COM APIs... The similarities are more than superficial (which makes sense, since some of the goals of VOS overlap with the goals of COM/DCOM). On Thu, Nov 29, 2007 at 10:37:37AM -0500, Reed Hedges wrote: Component is generic, and also recalls COM etc. How about: Part Facet Role Type Fragment Trait What exactly *is* a metaobject? It's a constituent Vobject that's part of a real Vobject, and which implements a facet or part of that Vobject, probably corresponding to a type. It implements part of the Vobject's interface. It provides an interface to the programmer (e.g. in C++ or whatever) for that facet or part or type. It handles a set or group of messages within that Vobject. I kind of like Part. Could even be inside Vobject's namespace I guess (Vobject::Part). I don't know how much this might have changed in s5 but generally a programmer only needs to know about MetaObjects when he is implementing one, if you're just using VOS you deal either with objects as generic Vobjects or with their type interface classes (e.g. Property, Object3D, etc.) Reed ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] thinking about a new web site
On Tue, Oct 23, 2007 at 02:09:11PM +0200, hellekin wrote: On Mon [EMAIL PROTECTED]:58:07 -0400, Peter Amstutz wrote: Anybody want to help do a new site design? *** I can give a hand on the new version. Great! As I wrote in the previous email, I think want to keep more or less the same set of sections, but do a new layout for the overall page template. So feel free to create a new style sheet, menu, header/footer layout, background, logo and so forth. Put up a sample page and link to it on vos-d and everyone can comment on it. How does that sound? -- [ 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
Re: [vos-d] S5 and ordering listeners
On Mon, Oct 22, 2007 at 04:39:39PM -0400, Reed Hedges wrote: Can you comment on this Peter? Let's say I want a set of listeners attached to an object to be invoked in order. Let's say that both listeners live on the same local site (process) and maybe are both associated with the same vobject. Will there be a way to do this in S5? What if the listeners are associated with metaobject types (e.g. a vobject L is linked to another vobject Source. Applying type X to L causes listener x to be created, and applying type Y casues listener y to be created, each listening to vobject Source (they find Source because it's linked to L). I always want x to be notified before y of any changes to Source. Does this make sense? I don't really follow, no. Could you give an example? The plan for listeners is for it to be based properly on message passing between objects, rather than straight callbacks. Once messages are sent out, there isn't really a guarantee on ordering, so if you need a strong cause and effect trigger, you should probably have an intermediate object that subscribes to the primary object, does some work, and then passes it on to the next listener... Or are you trying to do some kind of filtering? I can't answer the questions without knowing what you're trying to acomplish. -- [ 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
Re: [vos-d] thinking about a new web site
On Mon, Oct 22, 2007 at 07:56:09PM -0400, Reed Hedges wrote: Here are some ideas I had on revamping the web site. Graphic Design -- * Change the background to white or another light color. Maybe change the main content area to a different shade too, rather than current grey. * A set of background/side illustrations, that convey some of the more general themes of VOS and Interreality -- interconected things; multifaceted stuff; distributed structures -- but also look cool and have a computer graphics style to them. Sure. I did the current design a few years ago based on an even older design of yours (still online at http://interreality.sourceforge.net/ !!!) (we should probably take down the sourceforce page, although it is of historical interest ;-) Anyway, I don't claim to be a competent graphic designer, and the interreality.org cascading style sheet has grown completely out of control, so it is probably time to start over from scratch from a design standpoint. Anybody want to help do a new site design? Pages - It's great that the site runs on hypervos. Maybe we want to keep it, or maybe we want to switch to something else then go back to it. It would be great to have text in Vobjects that can be reused on multiple pages. Having updated the pages, I think it's worth staying with HyperVOS for now. We'll want to transition to an s5-based system eventually, but we need s5 first. If we use a wiki for the main pages, we'd need to hide all the meta wiki stuff. I've seen quite a few projects that use a more or less straight up wiki for their whole site, take http://bazaar-vcs.org/ for example. Hiding the wiki links does look more polished, though. Sections I don't think we really need a hierarchy [with the exception of About, see below], at least for the public facing aspect. These links can be listen in a little table or grid at the top of the page, like they are now (but set in a grid so they line up nicely, perhaps with logical groping/separation). * About [See below] * Screenshots * News [redirects to forum announcements] * Download * Docs * Forums * Mailing Lists * IRC * Servers [not at first, but eventually link to running servers] * Bugz * Contact That's pretty much what it is divided up into right now, minus a contact page, and no servers page since there are none. About Section/Docs -- My main concern is that so much stuff is changing, in terms of both overall goals (trying to be a more focused on addressing specific tasks) and in the specifics of the technology, its hard to write useful documentation until development has settled down a bit. -- [ 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
[vos-d] notes from IRC, pt 2
Additional notes on interreality3d gui from IRC. Participants: mm765, tetron - Had trouble moving the avatar. Determined that this probably stemmed from a combination of issues: - Initially tried to use WASD keys (typical first person shooter configuration). Interreality3D 0.1 doesn't bind these keys to movement. - The d key goes into drag and drop mode, which overrides the movement keys and is not obvious how to escape from (you hit escape). - Once figured out arrow keys for movement, reported stuttering movement. This seemed to be tied to resizing the window (?). Mentioned he was using Windows Vista -- interreality3d hasn't been tested first hand on Vista, so it may be an issue with that OS. - Reported crash when clicking on ? button, then closing the help panel. - Did not like having to push escape to cancel out of minor modes. Should at least be able to cancel mode using the same key that got into the mode. - Did not think splitting was a common enough operation to support having those buttons on the button bar. - Mentioned running out of space in the window when using the mouse to move. - Liked the ability to go back to previous views. - Suggested having view templates for set GUI configurations. I mentioned and we agreed this is the same idea as UI skins discussed previously on vos-d. - Suggested that chat view should be integrated as an overlay on the 3D view; a suggestion also put forward by winterk (I believe.) - Did not like Emacs-style multi-key chords. I pointed out that the majority of Ctrl- and Alt- prefix key shortcuts are already monopolized by the OS, other GUI controls or by convention, so there are very few shortcut keys available without getting into multi-key chords. - Agreed the the UI will probably become clearer once its purpose is clearer. Lacking the ability to do any interesting browsing or editing (which depends on the backend to supply that data) it requires a bit of imagination to see what the workflow will be like, and how a configurable UI plays into that. -- [ 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
[vos-d] notes from IRC
Notes from some initial discussion of the interreality 3d interface. Participants: winterk, zaharazod, tetron - Should be more like stuff people expect - Splitting and merging panels is likely to confuse casual users - Casual users should not have to mess around with the interface (splitting, creating new panels, changing modes, etc) - Suggested having a basic layout and an advanced layout to help casual users - Discussed implementing different layouts as UI skins which set up a particular panel/mode configuration for a particular task (browsing, editing, programming, etc). Skins could hide customization buttons like splitting. - Mentioned that even in a virtual worlds like Second Life where building is emphasized, the majority of users don't want to create, just use other people's prefab stuff. - But still important to make build tools accessable to ensure that curious users can get into it easily. - Suggested adding right-click context menus to 3D mode (good idea). - Suggested initial 3D panel after login should include chat panel (good idea). - Discussed different input schemes for controlling avatar movement. - Suggested that first person shooter WASD + mouselook is most immersive - Drawback is that it requires grabbing the mouse, which is incompatible with other user interface modes such as editing, where you want to stay in one place and grab and move things around with the pointer. - Discussed that the goal is for UI controls to be per-world configurable - The idea is that when you join a world, you download a bundle of scripts and key/mouse bindings which provide a customized the user interface to that world. - So the issue of what 3D controls to use is primarily an issue of preference or what makes sense for a particular application, and not one of policy - Key and mouse bindings could be reconfigurable by the end user. I think this idea of reconfiguring the UI for different worlds also fits nicely with the idea of beginning/advanced/task-specific UIs discussed at the top. -- [ 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
Re: [vos-d] notes from IRC
On Fri, Oct 19, 2007 at 05:40:40PM -0400, Reed Hedges wrote: I agree, this is something I suggested to Pete earlier. Do people want this feature added to the prototype, or wait for the real app? Well, the intention is for the prototype code to morph into the real application frontend, so work on it won't go to waste. It's called a prototype largely because the all-important network backend is a mockup, so it looks pretty but doesn't do the most important things the real app will do. So if this is something you'd like to work on, I encourage it. However, if the goal is to get something useful in peoples hands sooner, I think I should focus on identifying a minimal set of backend VOS functionality for version 0.2, implementing that, and porting the UI prototype to use the real backend. This is something that will make it really useful and work well, but is pretty novel AFAIK. I don't really know of any other application that does this, except that Javascript has a key handler so web pages can get keystrokes (except control keys). VRML does it similarly I guess. But those are all used by the content, neither of those is customizing the shape of the meta-UI. By comparison with the web, arguably the splitters are kind of like the much-hated web frames. It's worth considering why people hate frames so much, and make sure we avoid those mistakes. Also, I really want to support a floating heads up display (HUD) overlayed on the 3D view. My idea is to have some kind of vector graphics representation (based on SVG, probably) that can be used to describe floating HUD elements/UI controls. This actually would be quite useful independent of a HUD. It would be able to render to texture so you can interact with GUI elements in-world, and could be used for rendering generic embedded cross-platform 2D UIs (what people are trying to do with web apps these days). If we develop a really good 2D UI kit, we could throw out wxWidgets and just use our own vector-based UI :-) But I'm getting ahead of myself. So we need to think through how it works. E.g. should it automatically reconfigure, then show a message at the top notifying you that it did? Or should it ask first? Should it only allow configuration within the one pane that is viewing the Vobject that wants to reconfigure? Should it open a new window frame with the new configuration, leaving your old configuration alone? Hmm, well a multi-panel configuration is a bit different from a minor mode, which only affects a single panel of a specific mode. I'm not sure how to group it, although at the level of the entire frame would make the most sense. When you join a world, it could pop up a dialog saying, this would would like to set a custom UI, is that ok? As you mentioned, we'll have standard UI configurations that people can use as defaults or to build from to create their UIs. -- [ 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
[vos-d] interreality 3d 0.1 released
The first prototype of next generation s5 development branch of VOS has been released. This is a user interface prototype, intended to demonstrate progress, solicit feedback and get bug reports. Interreality 3D is supported on Windows, OS X (intel) and Linux. Download it here: http://interreality.org/download A few notes: - This is a prototype. It lacks major functionality, in particular it lacks any sort of networking backend. The purpose is to demonstrate user interface ideas. - Please sends us your comments, concerns and ideas, either to the vos-d mailing list, or on the web at the vos-d discussion board at: http://interreality.org/phorum/ - If you find a crash, please file it with Bugzilla: http://interreality.org/bugzilla/ I hope you find this prototype interesting, and it is a sign of much more development to come! -- [ 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
[vos-d] bugzilla
Pending the release of the interreality 3d 0.1 user interface prototype (that's a mouthful) I have set up bugzilla for bug tracking and feature requests. It's accessable on the main page and at http://interreality.org/bugzilla -- [ 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
[vos-d] cross-platform packaging
Just found this program to manage generating cross-platform (well, cross-Unix) packages. It takes its own package spec file and can generate native packages for a whole bunch of unix platforms, including deb and rpm. http://www.easysw.com/epm/ It supports OS X (?) but ideally we want to distribute the entire app as a single app bundle. Windows, as usual, is its own case. I'm planning on using Windows Installer XML (Wix) to generate Microsoft installer (.msi) packages. I'm still tinkering with the UI prototype (my current project is to add back and forward buttons to views enabling browser-style navigation) but I want to put it to bed soon so we can start working on concrete functionality in the backend. -- [ 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
[vos-d] progress and planning
The mailing list has gone quiet again, but that doesn't mean nothing is happening. I am presently working on the new UI prototype for VOS, which is shaping up quite nicely. The general plan going forward is: a) Finish the UI prototype. This has taken longer than I expected due to a combination of technical issues and having implemented a lot more ideas than I had originally. I'm hoping to be done with this in the next week or two. b) Create installer packages. I want to have one-click install packages for Windows, OS X and one or two Linux distributions. c) Release, and discuss the merits of the UI. It won't be particularly functional but it should give a pretty good sense of how you might use it and (for editing actions) what the workflow will be like. d) Turn our attention to the backend. I'll build on the s5 work I started last year, so hopefully I can put something together relatively quickly. My goal is to have a somewhat faster release cycle with the backend work, perhaps having a new release as major features (scripting, saving and loading, networking) are landed. e) Implement demos. Actually, we should start thinking about this even now. I've been thinking more about the big picture functionality, and I've decided that I want to focus on the simulation side aspects in a 3D environment. That is, to have a framework that makes it easy to create a virtual world, add some agents (avatars, NPCs, whatever you want to call them) and then push play. The goal will be to address the needs both of games/entertainment (which are essentially discrete event simulations, albiet with rules that are intentionally unrealistic) and more serious applications such as AI and robotics research. -- [ 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
Re: [vos-d] progress and planning
On Tue, Sep 25, 2007 at 07:44:04PM +0100, Marcos Marado wrote: Hi there, and thanks for the update. On Tuesday 25 September 2007 18:28, Peter Amstutz wrote: b) Create installer packages. I want to have one-click install packages for Windows, OS X and one or two Linux distributions. For the Linux packages, please go to Debian and Fedora. Those two are probably the best two plataforms to release the most clean .deb/.rpm packages for others to be able to repackage them for their own distribution. As I noted in the other mail, I'm looking into using the epm tool (http://www.epmhome.org) so we only have to maintain a single script to be able to build binary packages for multiple distributions (including both deb and rpm based distros). I personally use amd64 Debian, so I can generate 32 and 64 bit x86 deb packages pretty easily. To support Fedora, I'll need to set up another partition, or maybe a virtual machine. Hmm. -- [ 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
Re: [vos-d] development
On Tue, Aug 21, 2007 at 12:28:55PM -0600, S Mattison wrote: The goals for the UI prototype is to explore how to present a highly configurable user interface based around vobjects, to consider the kinds of tasks and workflow a user might perform in the GUI, and to confront cross-platform issues (in compiling, in the operation of the GUI and in distributing binary packages) up front, so that development stays honest and as OS-neutral as possible. Wait, so, you mean, you're rendering the UI widgets in 3d now? (It sounds more and more like Blender each day.) I'm not doing 3D widgets yet. The UI is wxWidgets with 3D windows (as well as other views, such as a tree view) embedded in frames. The frames can be split, unsplit, resized and detached at will, and each displays a different view which may be presented as a 2D control or 3D rendering, depending on the viewing mode. It does have some similarities with the Blender UI, but it would be more accurate to say that the UI I am working on is more inspired by Emacs (!) Eventually I want to be able to paint 2D views onto 3D textures so that you can mix 2D windows and 3D scenes freely -- but that will require a bit more work in creating/porting a GUI toolkit that can render to texture as easily as to the screen. By developing the UI first, I'm also taking a more top-down design strategy. In the past, developing the backend first has led to the UI and the sample 3D worlds being an afterthought, which of course didn't impress most users. To avoid making that mistake again, I'm going to focus on UI and content creation up front, to make good presentation and usability (and usefulness) a priority, and only then develop the backend to support those requirements. With Usability as a focus, you could attempt to allow users to create their own content, which I think should be the aim of a community-oriented project such as this one. More content means more popularity means more content, etc, etc. Absolutely. In fact since you mention it, I think I'll see if I can get the Blender - S5 Prototype export down to one click (writes the file, loads it into VOS for you). I'm hoping to have something for you all to see (UI prototype, with no network capability) in two to three weeks. Looking forward to it! -Steve Good to hear :-) -- [ 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
[vos-d] development infrastructure
VOS development (specifically the next generation s5) is officially back on track. I am now able to devote at least half of my working hours to VOS. My time so far has been spent primarily on infrastructure issues. I'm using the SCons (Software Construction) tool to develop a cross-platform build system. A lot of things that in s4 are done with shell scripts and Unix commands can be done much more portably with the Python standard library. The most useful feature for new developers will be automated downloading and compiling of dependencies, allowing one to start from scratch with only a few standard tools (Python, C++ compiler, make/nmake/vcbuild/xcodebuild as appropriate) and build VOS and all its dependencies with a single command. Most importantly, this means that there is only one set of files describing the build, so there is no need to synchronize changes across makefiles, vcproj files, xcodeproj files and so forth. However, since Visual Studio and XCode support makefile projects (which are easily configured to run SCons), you will still be able to use the IDE for development and debugging. In order to ensure cross-platform compatability I will be testing and developing constantly on several platforms. With the hardware sitting on my desk right now, I will be able to directly support Debian Linux (amd64), Windows XP (x86) and OS X 10.4 (x86). On Windows XP I am using Visual C++ Express, which is a free-beer download from Microsoft. Compiling on Windows requires only Visual Studio 8.0 and Python 2.4 -- no Unix tools required. I haven't played around much with Cygwin and Mingw yet, but adding support should be relatively easy. I intend to eventually implement a staged check-in system, where changes are run against a unit/regression test suite before being merged into the official branch. That won't catch all issues (particularly those affecting specific OSs, since the branch will be hosted on interreality.org, which is amd64 Linux), but should still provide a firewall against dumb mistakes and help ensure that the public development branch is relatively stable. It's been my experience with software development that the time invested in the software engineering process is paid back many times in time saved later, as many problems are caught before they are disruptive or can be avoided entirely. I'm planning for the hopefully not-too-distant future when we have several developers hacking on VOS and need to avoid stepping on each other's toes. -- [ 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
[vos-d] development plan
Here's the big picture for VOS development over the next few months: 1) Build out development infrastructure discussed in previous mail. This is mostly done. The two main tasks are to refurbish an old computer I have to run Windows XP (waiting on parts) and to deploy or develop a staged commit system as I discussed. 2) Work on user interface prototype. In the past, the end-user browser has always gotten the least attention despite being the first thing that everyone sees. I am working on a minimal (lacking the underlying VOS structure) prototype GUI to stimulate discussion about the nature of the application -- how it will be used by newbies, developers, artists, etc. 3) Create distribution packages for the user interface prototype. This serves two purposes: to enable people to try out and comment the UI without having to compile VOS, and to have the infrastructure in place to create .msi files, app bundles, debian packages, etc. 4) Concurrently with (2) and (3), I'm going to restart discussion of the s5 backend design. I think I've got it all laid out in my head, I just need to write it down so you guys can pick over it. 5) Come up with some milestones and prioritize development. The strategy will probably be to code enough of the VOS framework to support concurrent development of higher level pieces like A3DL, and to start putting some meat on the bones of the UI prototype. This may be something like scripting + A3DL + application frontend (which could be a useful tool in its own right) without the networking, distributed computing and persistance pieces necessarily being ready yet. -- [ 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
[vos-d] s5 design
The overall project can be divided up into three pieces, the backend, the middle layers, and the frontend. The frontend is the user interface (of which I will be presenting a prototype). The middle layers consists of code dealing with specific features, such as chatting, representing a 3D scene, how the 3D world is organized, login protocols, and so forth. The middle layer is heavily influenced by needs of the frontend and the capabilities of the backend. The backend is the object management layer that enables everything else -- it is the actual Virtual Object System. Here are some of the goals and key features for s5 backend: - Same basic Vobject model as s4, allowing vobjects to have multiple types and to connect to other vobjects through child links. - Vobjects now have an explicit computational/concurrency model based on Actors. Each vobject is a separate logical thread of control -- in practice this will be implemented as a mix of user (cooperative) and preemptive (operating system) threads. - API oriented around asynchronous message passing and futures, allowing a method handler to return control to VOS and continue when some event occurs. - Language independent. Vobject behaviors can be implemented in any supported programming language, and multiple languages can be used in the same process. - Object type definitions define cross-language interfaces and data models (such as A3DL). Use code generation and reflection to create proxies automatically. - Architechture plans for distributed processing. Vobjects can migrate between hosts. - Orthogonal persistance and caching. - Capability-based security and resource accounting (to eventually implement resource quotas.) I'll talk more about how these pieces fit together in another email. -- [ 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
Re: [vos-d] thoughts and plans
something useful at something faster than our current glacial pace. If GUI elements are somewhat modular as Pete seems to be suggesting (I.e. action/mode X means load GUI panes Z and Y) then we can eventually replace 3D versions if we want, down the road. It's also worth considering that 2D overlays of a 3D view have disadvantages as well, they obstruct your view of the scene and have to be repainted every frame. Having the 3D view embedded in a 2D GUI means the 3D view itself can be much less cluttered. That said, we obviously want to support 2D overlays on the 3D view, and have the option of providing an immersive view. But really the idea behind having major modes dictating the view is precisely to allow for having radically different views/interfaces to the same information. There's no reason the 3D scene would only have one possible view. This part is going to require a lot more design; one of the first things I am going to do is put together a GUI prototype (without the VOS backend) that provides a more concrete way of exploring this idea. If so, I am not sure what the mode stack in your mockup is for. Yeah, nont sure about this either. Is it a history of modes you used to be in? Sounds fine, the only problem I see is how to determine that the user is done with the current tool/minor mode. There sould be a consistent and obvious way for the user to signal that. The current mode should only be effective in the main part of the browser, with an unobtrusive reserved mode selection area that is always available and re-grabs mouse/keyboard bindings if you move the mouse over to it or hit ESC or something. Well, is this what the mode stack window is for? I think various tools could trigger mode transitions (bound to keys, mouse buttons, other input devices). Anyway, we can just put them all in a menu too so you can always have access to any of them as well. Actually the idea is that you have a mode stack, and when there is a keypress or mouse event, it searches from the top of the stack downwards to the default major mode map. The minor modes may be transient, for example you might push a rotate selected object mode to the top of the stack, this would alter the interpretation of mouse events (so that moving the mouse rotates the object on some axis) but not affect keyboard events. When you're done rotating the object the rotate mode is popped off the stack and the mouse behavior returns to normal. Some standard key (probably ESC) would cancel the current mode and pop it off the mode stack. The toolbox on the right hand side would provide a list of commands that are valid in the current mode. When I have some time I will put together a prototype to try and explore these ideas. It's hard to discuss in the abstract, and I don't know myself how this will work -- I'm modeling it after the Emacs workflow (sort of) but Emacs is centered around the concrete notion of a text buffer, whereas the VOS editor is operating on vobject structures which are considerably more abstract. -- [ 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
Re: [vos-d] What do we want in the 0.24 release?
Yea, we should probably have a minimum z value or invisible bounding box or something that prevents users from wandering out and falling off the edge of the world. It's a silly, trivial feature we keep putting off... On Fri, Jun 29, 2007 at 01:09:24PM -0600, S Mattison wrote: I mean in the Pyramid World. Outside the pyramid, there's only a little bit of room to run around before you fall of the edge. Perhaps at a certain depth, the player should respawn on the land, or inside the pyramid? On 6/29/07, Reed Hedges [EMAIL PROTECTED] wrote: On Fri, Jun 29, 2007 at 08:05:37AM -0600, S Mattison wrote: I can fall through the map. =P Well maybe you need a floor! :) Well, it's not difficult when there are no invisible bounding boxes holding me on. Actually it's several things 1. Bounds in the world that terangreal can check, plus maybe an option to turn bounds checking off 2. Option to turn gravity off/on 3. Option to turn collision detection off/on 4. A fly mode that is initiated by fly keys that turn off gravity while you're flying, then a key that turns it back on. 1. is pretty trivial, 2 and 3 are trivial, 4 is not too hard but would take a bit of work. ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] thoughts and plans
(I wrote this in a private email to Reed, but I think it is of general interest). What I have in mind could almost be a sort of desktop for VOS, providing a general framework for providing visualization and interaction for vobjects. Thinking about it in that way, it might be desirable to split different views into different processes, so they don't conflict with each other and a crash doesn't take down the whole system... That approach would make it kind of like a window manager or display server. I'm thinking something like: vos io - abstract handling of input and output vos 2d - retained mode drawing using the SVG data model vos 3d - rendering based on A3DL data model (as we come up with it) vos gui - Abstract GUI controls represented using SVG or A3DL VOS I/O is something we I haven't mentioned, but we will need a layer that explicitly knows about key/mouse input events, and provides an abstract representation for different means of output (character stream, text console, graphical 2D and 3D panes). I need to sit down and write some prototype code to explore this idea more. I'll probably hack out a GUI prototype with fake vobjects that provide core functionality without all the asynchronous communication/concurrency/network transparency features that will be in the real VOS. The week of June 9th I am officially part time, so that's when I hope things will get going. On Fri, Jun 29, 2007 at 09:09:36AM -0400, Reed Hedges wrote: I think we do need modes for keybindings, and I like the general tool idea. The GUI should not neccesarily be directly mapped to mode.n ia fixed configuration though. Instead, there should be a set of GUI elements (side panes, etc.) for each mode, but they should be flexible in that you can bring up other GUI elements, minimize elements, and it should remember that layout configuration for the next time you enter that mode. And, mode transitions should be tools/bound actions. For example, you define in configuration that middle mouse click means to select an object, and also enter editing mode with that object selected. By entering edit mode, the GUI layout for that mode would be displayed, which might include window panes with different toolboxes or information about the object displayed. But maybe you want some panes to always be visible in all modes, etc.; maybe you want to hide the chat pane while you're in edit mode or minimize it so that there's a little button on the edge of the screen that brings it back, etc. I think tool panes/sidebars that you optionally float and move or iconify are a useful way to present buttons, tools, and object trees that makes them easily accessible and viewable. (We should also definately adopt Firefox's method of displaying background notifications and non-modal dialog boxes by inserting them above or below the main viewing area rather than as popups :) Reed ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] thoughts and plans
On Wed, Jun 27, 2007 at 12:29:43PM +0200, Karsten Otto wrote: - Scalability, clustering and recovery from failure. The general ideas is to use replication for load balancing and distributed locks for consistancy control. This sounds like a radical redesign... so far we had a single local vobject acting as a sequencer for multiple remote vobjects. Obviously, you have something new in mind. Please tell us more :-) I'm shamelessly stealing from Croquet, actually :-) The general idea is to roll up clustering, caching, persistance and remote objects under a single replication design. After all, what is the purpose of a distributed system but for managing copies of objects? So, the focus of the design will be on locating, replicating and synchronizing objects, whether the copy comes from a cache, a site, or a member of a cluster. This has a few implications: - The core vobject data model needs to include property data (a direction we were already going with embeded children) so that the entire potential state of the vobject is known and explicit. - The vobject model needs to have a canonical serialization that can be used for checking hash codes. However, this won't affect the ability to have multiple encodings used for data exchange. - Vobjects will need revision numbers and possibly last-modified times used in conjunction with the hash code to assist in determining if a copy is out of date. Once the ability to read and copy vobjects is established, we still need to deal with how to write to them. The design will attempt to move away from explicitly differentiating between local and remote objects, and instead look at whether the object's site is local or remote. For remote objects, it is a simple matter of forwarding requests to the remote site [1]. In the case of clustering, the same site might owned by several processes, and a distributed locking protocol (or alternately a distributed transaction) will establish which node owns the vobject. [1] I'm still working on what kind of speculative execution should be allowed on the client side. It is easy to service a read request on a cached vobject, more difficult to execute code that will actually change this vobject and others, and could have a ripple effect on the system that would have to be rolled back if the request was denied. A couple of key differences from Croquet: I'm concerned primarily with replicating end results, not computation. Croquet works by requiring that all Croquet simulations accept the same input in the same order and produce the same deterministic results. This is troublesome in a heterogenous environment where different versions of software (and even entirely different implementations) need to work together. Second, I see distributed object ownership as being done primarily in a high performance or high load situation where a compute cluster makes sense. There's no reason it couldn't be done between peers on the Internet, but it requires parties trust each other -- distributed ownership implies that there is no way to enforce access control between peers. In most situations, which are more security conscious, you have a more typical centralized design (in terms of world ownership being located on a single site) accessed by clients which issue checked change requests. I should mention that clustering isn't planned for 1.0, but I'm considering it now to ensure the design and implementation will be able to grow and support it later. On a separate note, another goal is to support more data-oriented networking and routing, inspired by the Van Jacobson talk we discussed earlier. Fully qualified vobject identifiers will be address-independent (unlike s4, which uses domain names and as a result suffers from a number of aliasing problems) which will allow parties other than the actual vobject owner to route messages and serve vobject replicas, through careful use of digital signatures to prevent forgery. * It should be designed to permit plugins or extensions to its functionality. I would go a bit further here - use plugins as the *basis* of the software! The main client only needs to provide capabilities for displaying (layered) 3D content and manage plugins. Everything else should be in the plugins themselves. See below... Yes, I agree. The Emacs model is to provide a relatively small kernel of functionality, with virtually everything else built up as an extension. I'm hoping that the extensions can be written in Python and/or Javascript. The key insight for me is in considering, from a UI and application design perspective, what the kernel for the 3D VR browser actually needs to provide to have the right hooks that the extensions can grab on to. I'll see about replying to some of your other points about UI later (right now it's late.) -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer
Re: [vos-d] 3D engines
Well, one thing I was trying to get across is than VOS doesn't care that much about a lot of these game engine features, because we are going to be doing things our own way as part of our own design. I.e. we don't care if an engine has a native map format with scripting hooks, because we're going to be using A3DL and our own scripting system. We just need a good, high level 3D renderer. On Wed, Jun 27, 2007 at 12:29:10PM +0800, chris wrote: Hi Peter, just one comment, it is proly not right to compare Ogre with a 3D game engine. Might be better to look at a game engine built on Ogre - like GOOF. chris On 27/06/07, Peter Amstutz [EMAIL PROTECTED] wrote: Many of the support features of various engines (map editors, or support for certain modeling programs) are less useful for us, since we will ultimately need to convert data to and from the engine-neutral A3DL data model for transmission over the network. -- [ 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
[vos-d] thoughts and plans
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
[vos-d] 3D engines
The developer of the Lightfeather 3D engine (an offshoot of Irrlicht, since rewritten) has expressed an interest in working with us, so I wanted to mention the idea of moving primary development from Crystal Space to another 3D engine. Since I am rewriting Ter'Angreal either way, I don't have a strong opposition to changing engines, but I don't (presently) have a strong reason to switch, either. The crucial features are that it be cross-platform, fast, unobtrusive (easy to subordinate to the WxWidgets or VOS event loop) and support a few crucial features we need, like portals and skeletal animation. Other 3D toolkits I have considered include Open Scene Graph and Ogre. I suspect that at this stage of development, most 3D engines are more similar than different -- they all use OpenGL and the same shader languages (Cg or GLSL), which accounts for about 90% of the end result of rendering. Many of the support features of various engines (map editors, or support for certain modeling programs) are less useful for us, since we will ultimately need to convert data to and from the engine-neutral A3DL data model for transmission over the network. Thoughts? Lightfeather: http://lf.mmdevel.de/news.php Crystal Space http://crystalspace3d.org Open Scene Graph http://www.openscenegraph.com Ogre http://www.ogre3d.org -- [ 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
Re: [vos-d] Errors building crystalspace
On Tue, May 29, 2007 at 06:58:36PM -0400, Reed Hedges wrote: OK, it turns out this is just G++ 4.1.3 being stricter than older G++'s. Our CS branch actually had a partial fix for this problem but - bizarrely - it was conditional on the compiler being MSVC 7.1!! I looked at current CS svn and it just declares csPrintFormatter and IEEEwhatever::mantissa correctly to begin with. I'll commit this to our crystalspace branch. How do I regenerate the .tar.gz? Use /home/bzroot/vosscripts/makeexports Incidentally, crystalspace.tar.gz is humongous. To redownload it in less than a few hours on my dialup connection I went in and deleted a bunch of stuff from the scripts/msvc* directories, the entire data directory, and some of the plugin code we don't use. Maybe we should do the same for our branch (at least delete the data directory). Careful, I'm pretty sure there are some essential CS config files stored in the data directory. I might also change vos/m4/cs.m4 to only compile some of the CS plugins instead of all of them (many of which terangreal does not and will probably never use). Go for it -- anything that reduces build time is helpful. The main challenge wrt to CS plugins is that some plugins rely on other plugins, so it takes some work to actually determine which plugins we're using and which ones we arn't. -- [ 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
Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24
On Tue, May 15, 2007 at 11:24:07PM -0700, Ken Taylor wrote: The point is I've noticed that in 0.23 the blacksun pyramid seems a lot ... smaller than in 0.24. Or maybe the penguins are bigger. Also, if I have 0.23 and 0.24 clients connected to the same server, the 0.23 guys look like they're floating above the ground to the 0.24 guys while the 0.24 guys look like they're half way in the ground to the 0.23 guys. Obviously some scaling and origin placement has been tweaked between versions. I just wanted to make sure this was intentional :) -- and also suggest that re-scaling 3d data should be added as a cleanup task before releasing 0.24. (Speaking of which, is a goal/to-do/priority list for 0.24 coalescing anywhere?) Yes, I changed the penguin sizes in 0.24. I did the math and realized they were about 40cm tall, and were intended to be a bit bigger than that. The bigger problem was I was doing something dumb in 0.23, which was the code that loads the md2 models for avatars recenters it to make the origin the center of the avatar bounding box rather than at the avatar's feet. That's why the 0.24 guys appear to be halfway in the floor when viewed using 0.23. Also, the avatars feet not touching the floor has to do with the collision bounding volume not matching up with the avatar (which is something else I was fiddling with). Since most of the work has gone into the network layer, a lot of stuff in the 3D layer was a quick proof of concept rather than being really well thought out. Even if s4 - s5 transition wasn't necessary, an A3DL redesign was already on the plan. Also it made me think about standardization. Obviously, VOS/Interreality3D will eventually have to have a golden standard for networking and data encoding. But also obviously, there will be lots of tweaking until a good standard is found (given VOS's code-evaluate-recode development approach). Speaking of the code-evaluate-recode cycle, I want to mention here that that come July, I intend to go part time on my current job and spend the rest of my time on VOS, which should work around to around 20 hours/week. Although it's not full time, I expect this to make a huge difference in the pace of development, especially since the majority of design work has already been done, so most of the work is will be just sitting down and coding. Until that standard is finalized, everyone will have to make sure they're using the same version of clients, servers, and data sets, to ensure consistency. But at some point, perhaps VOS/Interreality 1.0, a standard needs to be set in stone, with a guarantee that objects will be interpreted in consistent ways, that newer versions will be backwards-compatible, and older versions will fail gracefully if presented with newer data. A standard that's unambiguous enough that a person who's never seen the VOS codebase could write their own client and server from the standard itself, and also guarantee that compatibility. Well, that's a pretty tall order, and codifying standards is premature until we've settled on something that works. However, what is important at this point is to plan for backwards compatability, which is something I mentioned in an earlier email. In s5, I want to lay out a set of rules by which certain object fields and message signatures can be automatically casted, sliced or extended to allow structured data not conforming exactly to expected format to be converted. I think VOS should be able to offer very good compatability and consistency by providing the developer with guidance on what kinds of interface changes affect backwards compatability, and giving some flexibility so that not every teeny tiny little change requires an incompatible upgrade (which is the situation with most protocols in general, but virtual world systems in particular, such as Second Life having to frequently distribute client patches and reboot their grid). So rest assured, it's something we're thinking about, and have been thinking about for a long time -- making it general purpose and doing it right is one of the reasons VOS development has taken so long. -- [ 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
Re: [vos-d] Scaling and Origins -- 0.23 vs 0.24
On Wed, May 16, 2007 at 12:10:21PM -0400, Reed Hedges wrote: On Wed, May 16, 2007 at 10:18:34AM -0400, Peter Amstutz wrote: The bigger problem was I was doing something dumb in 0.23, which was the code that loads the md2 models for avatars recenters it to make the origin the center of the avatar bounding box rather than at the avatar's feet. So now it uses the bottom extent of the md2 model as the origin for the vobject's polygons? Shouldn't it use the same origin as in the md2 model, and if the origin is wrong there you just have to fix the model? (Or I guess we could have a flag in a3dl:model that decides this, since it's possible that people won't want to have to go back and change the source models, especially if you have a nontrivial workflow involving several artists and programmers). Unfortunately, just fix the model is often much harder than it sounds in the real world. For example, a lot of 3D models in the wild are exported from 3D modelers rather than being in the native modeler format, so you lose useful editing data, or maybe you have the original model file but don't have the right version of the modeling program that was used to make the original model. 3D file format compatability is such a big problem that this can even happen in organizations that might want to reuse content made for an earlier project. In this case fiddling with the model in code was due in part because I already needed to rotate the md2 model by 90 degrees so that it faced forward (this to get around a bug in the underlying md2 loader in Crystal Space). For the s5 redesign, I would prefer to avoid the current a3dl:object3D.model approach entirely, which was just an expedient hack to be able to leverage the Crystal Space modeling loading at the cost of the model data being opaque to A3DL. Instead we should write filters that convert to/from a unified A3DL format. Normalization should happen in the import step, rather than in the client. -- [ 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
Re: [vos-d] delineation and revision control
Let's see if I can clear up a few things... Bear in mind that the design is still evolving in my head :-) a) From the perspective of VOS, which is concerned with synchronization, the most important purpose of versioning is so you have a basis for deciding whether your replica A' of vobject A is current or out of date. Being able to record changes and go back into the history is just a nice side effect. b) Each vobject would be versioned separately. The child list is part of the versioned state, but a change to a child vobject should not affect the version of the parent. One exception: embedded children (property fields) do affect the version. c) The big picture I'm going towards here is that remote vobjects, caching, scalability/load balancing and the kind of broadcast routing Van Jacobson talks about are all basically cases of replication. If the VOS design can unify these cases under one general solution then we've won. I need to develop the idea more, but I think one key idea is relaxing the idea of a site so that it doesn't have to be tied to a specific host. I had already decided that sites would be identified by their public key, so that messages distributed by the site are self-verifying (by checking that the digital signature matches the site id). This means if you want to query a vobject, any replication -- the actual host site, a local cache, a third party -- can answer, and you can check that the answer did in fact originate from the site. What's really interesting is that this means the authority to publish changes to vobjects rests in who has knowledge of the private key that corresponds to the site's public key. If you wanted to do load balancing/clustering, you could share that private key among several trusted hosts, any one of which would be able to issue official state changes for vobjects on that site. I should point out that in the most common case, hosts will be in direct contact with the actual site, and receive messages published from the site directly, so it's not any different from the way things work now. Getting back to Kao's question (which I've wandered quite far away from), as noted the synchronization principals in the system are the site and individual vobjects. I don't see how cycles and bounderies between subgraphs factor into it, except perhaps in the initial phase of determining the specific subset of vobjects on the site you're interested in. On Wed, May 09, 2007 at 11:45:50AM +0200, Karsten Otto wrote: Well, Lars' suggestion of versioning only interesting parts and your suggestion of horizons seem reasonable, but I don't think we have the basis for this in VOS. A vobject usually cannot live as isolated entity, but *requires* a number of relations to child vobjects to make sense; thus any user-percievable world object is actually a subgraph of the overall world graph. The problem is delineation: It is not clear which subgraphs represent independent world objects, or if there is even a distinctive decomposition. For example, two objecs may share a texture - which vobject does it belong to? If you change one vobject, do you include the texture in the version? Where do you stop following relational links? I don't recall if there is any prohibition in VOS against cycles in the graph - I think there isn't - so matters become even more complicated. The only separation I currently see in VOS is the relation between the site vobject and its children, but even here it is not clear which children represent aspects of the site itself, which are scenery, and which are avatars. Any suggestions? Regards, Karsten Otto (kao) ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Van Jacobson: named data -- revision control
I don't think Jacobson was suggesting that a really new paradigm in networking would be able to handle the robust case of broadcast data, of which unicasting is simply a subset. I find you need a little creativity to fill in some of the gaps in the later part of the talk, since he wasn't presenting a design (or really, even a complete theoretical architechture) but simply some big ideas that he thought were worth a lot more attention. Packet switched networks are fine for realtime communication, provided there is enough bandwidth and they arn't congested. That performance degrades rather than simply shutting down and/or denying new connections is a feature, not a bug. As you point out, no existing system adequately fufills the requirements of online virtual worlds which precisely why we've spent so much time building our own. The problem is a curious mix of large quantities of mostly static data (3D models, textures) punctuated by dynamic data with high frequency changes and requirements for low latency. Throw in streaming media to the mix (voice) and it's really an architechtural nightmare when you consider the vast majority of network research has been in trying to solve each of these problems in isolation and to the exclusion of the others. The reason broadcast routing is so exciting is that we're not just trying to solve how to move the latency-sensitive high-frequency bits around, but that distributing and caching static resources (geometry, textures) is a huge part of the problem, and one that we never adequately addressed in the current/old s4 design. Indeed, moving the latency-sensitive high-frequency bits around is easy, because there isn't that much of it, and the problem was largely solved by online games ten years ago. On Wed, May 09, 2007 at 12:10:16PM -0700, dan miller wrote: Hi -- I'm new to the list though I have been on IRC now then. I loved Jacobson's talk but one point struck me: the introduction of a new paradigm doesn't obviate the need for the old. Packet-switching is great for fault-tolerance when the goal is get this packet from here to there, no matter what. It's actually the postal paradigm (thru wind sleet...) But the old telco real-time, hard-wired point-to-point connection was actually better suited to some things we do today over packet networks, particularly teleconferencing. The control over latency and timing is lost when you switch to TCP (as you VOS folks know only too well). A data subscription model is really just a cool technological way to introduce the concept of publishing to the digital world in a useful way; but it doesn't change the fact that packet-switched networks are not so great for realtime communication. WRT VOS/Interreality goals, in particular avatar/object behavior (whether scripted or resulting from user input), we have a mix of requirements that doesn't easily fit any model I'm aware of. It's time critical, like a phone conversation; it's point-to-many-point, like publishing; it's ephemeral, like broadcasting; but it's not fully global, in that typically you only care about a few objects in your virtual vicinity. Distributing this data liberally is not an option due to bandwidth. The bittorrent model doesn't really wash here because of the requirement for low latenc. I think in this case we have another animal entirely, which is basically a secure multipoint channel cluster. The closest analogy I'm aware of would be multi-party teleconferencing. ATT actually does this pretty well. This animal should be optimized for its intended use, and not shoe-horned into paradigms that it doesn't really fit. It might be reasonable to take a look at some of the ITU work in this area, such as H.323, and even the IETF VOIP/SIP stuff that's out there. I'm not saying we should necessarily adopt any such standards; but it is often worthwhile to take a good look at how similar problems have been tackled, for better or worse. Otherwise you risk spending mucho time reinventing various types of wheels. -dbm -- [ 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
Re: [vos-d] Van Jacobson: named data
Well, on a technical level you have digital signatures that give you a technical way to verify that information from a given source has not been tampered with. Provided you trust that the public key used to sign that data did in fact come from that entity, of course, but trust has to start somewhere. On a social level, you're right, people tend to introduce errors (either accidentally or deliberately) in information. There isn't a technical solution to that. But that's not the kind of transmission we're dealing with; we're only concerned with exact digital copies. Whether the source itself is an eyewitness account, a newpaper article or a wikipedia writeup, the goal is simply propagation of the actual digital document without allowing for the introduction of errors into the document itself. On Mon, May 07, 2007 at 10:20:55PM -0500, Len Bullard wrote: Versioning yes, but also vetting and revetting of sources. The further you get from original sources in any communication system, the more noise you incur without adequate checks. Shannon 101. Names alone won't do it. I put a trivia test at my personal blog just for a Do you trust Google and Wikipedia test. The problem is one of not starting from an authenticated or original source. If you start from wikipedia to answer those questions without the original source, you will get about half of them wrong or near wrong. Modern Internet traffic worries about efficiency but typically the data is short lived. If you live where I live you get to watch a fascinating change: NASA is hiring as many sixty and even 70 plus year old engineers as they can find if they have actual J2 series engine experience. The original sources and digital systems failed to keep enough documents alive. They have the designs but like the Canadians who tried to rebuild the V2 engines for their contest submission, they don't know how to run them and it turns out the devil is really in the details. len -- [ 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
Re: [vos-d] Van Jacobson: named data -- revision control
On Tue, May 08, 2007 at 03:56:07PM -0400, Reed Hedges wrote: There are lots of ways to do version control in VOS-- we already have it partly implemented. One important thing that we need to decide is how to expose particular object revisions to remote sites. I think we need to be able to refer (by URL) to both the current version, or to any past version (in all ways as a normal vobject, with all interfaces, etc.) Right. I think the key is going to be to start thinking about remote vobjects as simply replications of the actual vobject, and which means those replications use the same system to be stored on disk (cached) or passed around. The vobjects just happen to be associated with a different site; but I think it's worth considering relaxing the concept of site to its simplest form of a set of vobjects covered by a common public key, and that sites have a standard (replicated) vobject that contains its contact information. Then if you ask one host how to get in contact with some other site, it gives you that replicated contact information. Another crucial aspect of replication that keeps coming up is computation: I think when we replicate vobjects, we'll need to indicate whether it's computation can be replicated as well. As I stated in my previous email, this could be don't replicate (can't do anything with an object without contacting its original site), predictive replication (both contact the server and do the computation locally) or full replication (always run it locally and don't contact the server). I've been thinking about replication a lot due in part to reading about how Croquet works. However, where Croquet assumes a totally deterministic system (which makes replication of computation easier), I want to allow for a little more slack, provided you always have the ability to bring everything back in line. This is worth thinking about more, since it has pretty fundamental design implications, but is also central to how remote vobjects work, to caching, to versioning, and to scalability across multiple nodes. What's interesting is this is a shift not in how vobjects themselves work, but in how they move between hosts. I also think that for all this seeming complexity, that in fact in the cases where it matters, most of that complexity shakes out and it can still be very efficient. This means that if that version object is mutable, i.e. a not read-only property, we need to also have branches in the version history, and any reference to a past version of a vobjcet is really a reference to the most recent version in the branch rooted on this object, which if there is only one version in the branch, is the same as the root object [if that makes any sense]. I don't understand. Lalo will undoubtedly correct me if I'm wrong, but it seems to me what is most important is linear version history leading up to specific object. Branches mark the point at which item Y diverged from item X, which in this case would likely mean item Y would be given a new vobject id, or possibly have the same id but located on a new site. We could save the fact that it branched as metadata (maybe a core:branch-history vobject type), but it shouldn't be part of the fundamental vobject id. I should point out here that you don't actually *have* to keep a version history around, that's just a nice side effect. So long as you bump up the version number with each change (and timestamp, and regenerate the digital signature, etc) you have a simple way to compare your vobject replica with the master version on the site to decide if you need to synchronize or not. -- [ 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
Re: [vos-d] Jerky avatar movement (was Re: Patches for 0.24 in MSVC)
On Sat, May 05, 2007 at 02:04:01PM -0700, Ken Taylor wrote: Wait... unless the purpose of rot *was* to caputre and restore the previous position, and force all position updates to go through the setPosition/notifyPropertyChange mechanism in that case, the main problem is you can't guarantee that the property change will trigger a syncPosition that executes *before* syncView reads the new position. So what was happening is syncView had the latest position, but the mesh hadn't been moved there yet, so the avatar lagged behind in some frames causing the jerky movement. Pretty much, yes. To be perfectly honest, avatar control in ter'angreal is kind of a hack. I think immediately moving the mesh upon a local move command isn't such a bad idea, but the fact that an asynchronous property update gets triggered and executed at some time in the future, which *also* moves the mesh, is a bit troubling to me. This is also concerning me because it impacts my interpolation code -- what happens if you do a local moveTo on an object that also can be moved remotely? When do you interpolate and when do you update immediately? Any thoughts on what the Right Way to implement this would be? I'm not sure... As you note, it's tricky because you have both local movement commits and the possibility that it can be changed remotely, and that change should stick. It's kind of a race condition, actually, which is why it's hard. The Right Way is probably to fix the semantics of property updates to handle this better, but that's more of something to consider for s5... -- [ 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
Re: [vos-d] build system reviews (long)
Uh, I don't think giving everybody accounts on baikonur (the interreality.org server) is going to solve much. For one thing, it only runs Debian, and a big part of the discussion here is how best to support building on Windows and OS X. We intend to do 3rd party world hosting at some point in the future, but that will go on a separate box from interreality.org. I don't want to take the risk of a rogue script disrupting the box that handles our email, web page, mailing list, bzr repositories, etc. On Thu, Apr 26, 2007 at 01:02:08PM -0700, HEBLACK, J wrote: On Thu, 2007-04-26 at 09:21 -0400, Reed Hedges wrote: On Wed, Apr 25, 2007 at 11:07:11PM -0400, Peter Amstutz wrote: [1] Although there is a case to be made that such files should be included in your repository anyway, since there are people who might want to check out the latest source for something but still don't want to be required to have every last little build tool. Thoughts? Hello people, How about installing a sandbox or build sandbox at the main VOS station for devs to link scripts, Java, JavaScript, ..., whose scripts would not disturb Lead Programmers or VOS Architects. Thoughts? The official sandbox will have network constraint conditions saying that what is built officially is there for the VOS station only and not other networks? A sample devs account is like this: the first six letters from the devs last name followed by the first initial from the devs name; like this: [EMAIL PROTECTED] -- JASON A HEBLACK [EMAIL PROTECTED] APT 3 (650) 289 - 0954 450 EAST O'KEEFE EAST PALO ALTO, CA 94303 ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 scripting (design part 3)
will be used for, and so they should be allowed to do it. However, for breaking out of the sandbox in general, with a capability system we can grant relatively narrow and specific rights to a script that requires escalated privilidges. 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. I haven't decided how to handle sending code from the server to the client. One approach would be to go to the relevant type vobject on the server and retrieve the remote interceptor which provides the remote vobject behavior that acts as the proxy on the client for the real vobject on the server. Everything I have said here about server-side process accounting, resource limits and security applies equally to both the server side and client side. You don't want a malicious script to take over your desktop any more than you want it to take over a server with hundreds of people on it. The main difference is that on the client side we have the option of asking the user if something is acceptable, instead of just rejecting it outright. Deciding whether to actually run a script based on some client preference (maybe it's an annoying dancing advertisement) rather than having evidence of the script misbehaving is rather more difficult. 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)? Yes, we'll want some way of asking the server it's configuration, to find out what scripting languages (among other things) it supports. Letting mobile code be written in languages seems like a recipe for disaster though, since the two implementations were identical (and the standard well documented), you might get significantly different behavior in one runtime compared to another. I suppose you could translate from one programming language to another automatically, but I've never seen that done well... Since detailed process accounting for CPU and RAM are going to be hard to accomodate with existing scripting systems, the idea for the time being is to use existing scripting languages, but in a trusted capacity -- we might enforce the VOS security model for vobjects, but not worry about so much about CPU, RAM and disk usage. This should allow us to support a few languages on the server right off the bat. However, this is unacceptable for mobile code. For code that is transferred over the network and is run on the client or server without user or admin intervention, we will need to identify some runtime system that satisfies our strict process accounting and security requirements. This will probably end up being the default language at least so far as client and server side scripts written by untrusted users are concerned. Ideally this would be a virtual machine and not just a single specific language. I haven't found a good open source implementation of a virtual machine that satisfies our requirements, yet. So to sum up, for me the biggest challenge of scripting is to make it bulletproof secure, so that it can't be used by either clients or servers to take advantage of the other. I'm hoping to use a capability system to enforce security in interactions between vobjects (which I will try to do a writeup on soon, that will be part 4 of the s5 design) but process accounting to see that everyone gets their fair share of CPU/RAM is still a huge challenge. I don't want my scripting languages in a sandbox, I want them in a bulletproof jail cell... 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. Reed and I have been thinking about doing this for years. The idea was to use OpenVRML to provide the VRML runtime environment, and then translate VOS events to VRML input and vice versa. I think it's feasable, we've just never had the time to implement it. -- [ 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
Re: [vos-d] VOS on Solaris?
On Wed, Apr 25, 2007 at 11:33:49AM +0300, Lars O. Grobe wrote: Do you have libtool installed? That is a separate package from autoconf and automake. I compiled the most recent one from GNU. As I am not root, I installed it in my home and added it to my PATH. Does the build make any assumption where to find libtool (e.g. under /usr)? I think you need to also set an environment variable to the installation location of libtool, but you will have to check the documentation. When I was developing on Solaris I had to set up autoconf/automake/libtool to run out of my home directory as well, so I know this setup can work. Also, to be honest the last time I ran VOS on Solaris was maybe 3 years ago. I haven't had access to a Solaris box since then. Also, at the time I only had the server components running on Solaris, not the client (due mainly because I only had ssh/remote X access and was not at the console). Would it help to give an account on a Solaris/Sparc box? Of course, ssh again. It would help, except that right now my time is severly limited so I don't know when I would actually be able to do it. -- [ 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
Re: [vos-d] VOS on Solaris?
On Wed, Apr 25, 2007 at 03:47:11PM -0400, Reed Hedges wrote: Lars O. Grobe wrote: Do you have libtool installed? That is a separate package from autoconf and automake. I compiled the most recent one from GNU. As I am not root, I installed it in my home and added it to my PATH. Does the build make any assumption where to find libtool (e.g. under /usr)? You may have seen Peter's recent message about changing the build system. Pete, if we're not using automake, then we wouldn't have to use libtool either, right? Please note that the discussion about alternate build systems is for s5 only, I have no plans at this time to redo the s4 build system (although as a way of further evaluating build tools, I may apply them to building a part of s4 to see how they perform on real code and not a toy hello work project.) Otherwise, yes, half the reason for ditching automake is to get rid of libtool. Libtool has many quirks, a number of limitations (not supporting the MSVC compiler being the biggest one for us) and is ironically not abstract enough in a number of ways. For example, it can't accept that DLLs on Windows don't have to start with lib and it doesn't understand how to build frameworks and app bundles on OS X. Despite being written to support portability, the portability libtool offers really only extends to classic Unix OSs. So my preference is to switch to a build system with more modern sensibilities. Also, is jam is available on various systems like Solaris? Yes. Although the software I've seen that uses jam typically includes the jam source code in a tools directory, along with a shell script or batch script to bootstrap it (the script builds jam and then uses jam to build itself). -- [ 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
Re: [vos-d] Patches for 0.24 in MSVC
Ok, I'm looking forward to looking over and merging this, looks like lots of good stuff, but I'm swamped right now so like your other email it will probably be a few days before I can get to it. In the meantime Ken, if you're looking for something to do, I'd be very interested in your take on Jam vs Scons vs Cmake (see my earlier email for details) from the perspective of a mainly Windows developer. On Tue, Apr 24, 2007 at 08:17:38AM -0700, Ken Taylor wrote: For your consideration, Attached are a bunch of patches for the code changes I made to get 0.24 built and running with MSVC. I didn't include any of my changes to the vcproj/sln's -- just the codebase itself -- as those were a bit more on the hacky side. Some of these I think represent actual bugs, so I've marked them with **BUG**; others are portability issues that I've marked with **PORT**. Ones I've marked with **FIX** I think are solid fixes that I would suggest merging into the codebase, whereas others marked as **HACK** are hacky solutions that probably need a cleaner solution contrived for them. Unmarked ones you can take or leave, I guess I've tested building and running wxterangreal and omnivos in both MSVC and MinGW on windows with these fixes, using the demo project and also connecting to the world at interreality.org, and they seem to work across the board. Be aware, however, that I've only tested in debug mode -- no release builds yet. The only thing I haven't really tracked down is that avatar movement seems a bit jerky in the MSVC build. If I get more time I might look into it... Without further ado: vos: apps/omnivos/plugins/demoplugin.cc - HAVE_UNISTD_H wrapper **PORT** - for new_DoorBehavior and new_ChatBotBehavior **BUG?** - in case misc:clickable metaobject hasn't been added yet, add it. - this one is strange... it seems that on my computer, the XOD loader doesn't add metaobjects to the class in the order specified in the file, but rather in alphabetical order. So the demo: objects get processed before the misc: objects, but unfortunately the demo objects assume that misc:clickable exists, which caused crashing for me. My solution was -- if it didn't exist yet -- check if the object had the type, and if so, do an addType to get the metaobject initialized. I'm not sure if your design intends metaobjects to load in the order specified in the file, so I don't know if this is the right fix or not. - force port 80 on wikipedia.org **BUG** **HACK** - really the fix should be in the URL class, but I'm not sure how much else in the codebase depends upon its current behavior. apps/terangreal/ter_util.cc - Terangreal::drawTextTexture: arrow only has 3 vertices, not 4. **BUG** **FIX** libs/vos/extensions/http/httpclient.cc - define winsock2.h first, so it can exclude winsock.h **PORT** - winsock.h gets included somewhere later in the header chain, but I didn't pin down where. Other options are to explicitly exclude winsock.h ourselves, or I think defining WIN32_LEAN_AND_MEAN works, but I didn't try it. - use closesocket() instead of close() on windows **PORT** **FIX** libs/vos/vos/vosapp.cc - HAVE_UNISTD_H wrapper **PORT** libs/vos/vutil/getaddrinfowrapper.cc - #if 0'd out the custom versions of getaddrinfo, freeaddrinfo and getnameinfo **BUG** **HACK** - the custom code didn't work -- it crashed if hints was 0, and didn't do any service lookup - note! for windows 2000, this will build using the MS SDK, but not in MinGW! libs/vos/vutil/sleep.h - put parenthesis around macro parameter extraction. **BUG** **FIX** libs/vos/vutil/snprintf.hh - use _snprintf on win32 as well as mingw **PORT** - the custom snprintf had some bug in it that I didn't track down. crystalspace: include/csutil/win32/csconfig.h - define CS_NO_NEW_OVERRIDE **HACK** - not sure what the best solution is. MSVC was just having a hell of a time handling the new override with our code. I think variables were getting created with the standard new and deleted with the CS override new, which is bad. plugins/video/canvas/wxgl/GLWXDriver2D.cpp - add SetFocus() to csGLCanvas::OnEnterWindow **BUG** - I'm not entirely happy with the default behavior to steal focus whenever the cursor floats over the render view (it can steal it from dialog boxes, etc) -- but apparently this is how things were originally. I'm not sure what you want to do with that code that broadcasts a focus event to crystalspace. wxwidgets: include/wx/msw/setup.h - define wxUSE_GLCANVAS to 1 **PORT** **FIX** src/msw/main.cpp - change WXMAKINGDLL to WXMAKINGDLL_CORE **BUG** **FIX** Enjoy! -Ken -- [ Peter Amstutz
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
[vos-d] Lindens opening up the Second Life server
Linden Labs has made another statement that they will soon opening up the server. Not a suprise, but has touched off another wave of speculation about where they're going with it: http://www.3pointd.com/20070328/platforms-and-technologies-panel-at-vw07/ People have pointed out that a number of technologies SL depends on are themselves proprietary (such as the Havoc physics engine) so whatever they release is probably not going to be 100% free software. I think that the strength of VOS going forward (particularly embodied in the new design) will be the ability for the object model to interoperate with other systems on their own terms, so we can still play to the strengths of VOS on either the frontend or backend (depending on the application). The big players in virtual worlds are starting to emerge, but it is still early in the race, and we're in it for the long haul... -- [ 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
Re: [vos-d] S5 and single-thread option
On Fri, Apr 20, 2007 at 01:52:39PM -0400, Reed Hedges wrote: Pete, in your description of S5 so far it seems like it is defining a threading model that is not neccesarily coupled to a particular thread implementation. That is, conceptually vobjects are threads or proceses but I am guessing that you won't be implementing it by simply creating a pthread for each vobject :) Does this mean that it will use a thread pool of some kind? If so, would it be possible to have a thread pool of size 1, thereby making it possible to run VOS on an OS that effectively has no threads (I'm thinking of stuff like handheld devices, phones, embedded systems, whatever). Yes, actually one of my goals is to ensure that the system could be run in a single-threaded mode to be useful for applications like discrete event simulation. For network code we're likely to want to have at least one thread that handles socket activity, but if necessary that could also be something that gets called periodically from the toplevel event loop. Obviously I would like to avoid the recursive-runloop stategy employed by s3, so this will require that all behaviors are written using continuations so that if they have to wait, we can unwind the stack and control can be returned to the top level. But normally there would be a thread pool. Ideally, most of the time most vobjects are unbound which means they arn't running on any thread. Vobjects might even be swapped out to the persistance database if they arn't being used. -- [ 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
Re: [vos-d] URL::parse problem
Actually, I'm pretty sure the HTTP_GET() function ignores the port on the URL object and asks to connect to the http port (which should be looked up in /etc/services). Perhaps that should just specify port 80 explicitly. But you're right, the VOS URL class is highly VOS-specific in specifying 4231 as a default, which is kind of silly. On Wed, Apr 18, 2007 at 10:55:44PM -0700, Ken Taylor wrote: So I tracked down one of the problems I'm having with the wikipedia demo object: It's trying to connect to http://en.wikipedia.org:4231/ -- turns out if you give the URL parser a URL without a port, it will add 4321 as the port! That seems kinda silly to me, since default port is a protocol-specific thing. I'm surprised this has worked for you (assuming you've been using it as is) -- oh well, I'll just force it to :80 in the wikipedia object and see how it goes from there. -Ken ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Thinking about Javascript
Well, one approach would be to treat HTTP as an unreliable/stateless channel, implement stateful, connection-oriented sessions on top of that, and then have VOS (both on the server side and in the browser) run on that layer. So then it would easy to push updates to the browser by queuing messages until the next time the browser checks in. On Wed, Apr 18, 2007 at 11:39:06AM -0400, Reed Hedges wrote: Yeah, this is why I was looking for libraries out there that address these things (so we wouldn't have to). So far I'm only aware of comet and dojo (dojotoolkit.com) (the client side). Probably the best thing is to focus on just updating HTML in the browser. So if the browser opens that persistent, listening channel, then Hypervos can listen to the Vobjcets on its behalf, and if it e.g. sees a child-inserted and the new object is HTML/XML, and it also has an open connection to a listening web browser, to serialize the new objects into an HTML fragment and push that to the browser. Similar for anything changing in the objects or something removed. stick the new or changed HTML into the DOM (set innerHTML or something). Anyway, I'm just trying to gather ideas for future web applications, I probably can't work on this right away-- but if you want to that would be great, let me know and we can coordinate. I've been gathering these ideas at http://interreality.org/wiki/HyperVosIdeas . Part of my motivation has been searching for a good web application focused on Question and Answer customer support, as well as general forum discussion. -- [ 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
Re: [vos-d] VOP patches for 0.23.0
Great, I'll take a look at these and see if it still applies to 0.24. On Tue, Apr 17, 2007 at 11:24:58AM +0200, Karsten Otto wrote: Hi again, while I am at it, I thought I'd send the patches I am currently using to switch VOS back to the VOP protocol. For most applications (in particular mesh and omnivos) you can use the flag --proto=vop, but some do not support it (in particular the CS plugin, wxterangreal, and a3dldemo). Btw. the a3dldemo patch also fixes a number of permission problems, which would occur even if you used it with VIP. Enjoy! Karsten Otto (kao) -- [ 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
Re: [vos-d] Terangreal crash
On Tue, Apr 17, 2007 at 11:00:09AM +0200, Karsten Otto wrote: Hi all, Reading about Trer'angreal crashing or hanging, I just recently discovered a small bug in the message handling of the 0.23.0 release. Of course this is regarding the VOP protocol, which probably nobody except me uses anymore, so I am not sure anybody else is affected :-) During normal operation wxterangreal sometimes came to a screeching halt with the obscure error message Remote site error: Protocol violation: negative number attribute I tracked this down to libs/vos/vos/ messageblock.cc:XmlParser::parseNumberAttr, which basically does this: int res = (int)strtoul(start+pos+1, end, 10); if (res 0) throw ProtocolError(...) [snip] Is the range check actually necessary in this method? I don't have the time to track this down... You're right. I'm an idiot. The variable res should be an unsigned int, and the range check is unnecessary. I have no idea why that code is there, and I'll take it out. Despite of this obvious bug, I am pleased to see that VOP still sort of works despite the long neglect :-) I'm glad it's been useful to you. It's also proven to us the value of supporting multiple protocols that focus on different aspects like performance or ease of interoperability -- hopefully s5 will finally support multiple protocols within a single session :-) -- [ 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
Re: [vos-d] Got wxTerangreal to build in MSVC++!
On Mon, Apr 16, 2007 at 11:34:40PM -0700, Ken Taylor wrote: Woo! It's been an epic adventure, but I'm successfully running wxterangreal built from scratch (and boost, wxwidgets, and CS built from scratch, too) through Visual C++. And I should still be able to build with mingw, as well, so I can verify any changes against the two different build systems simultaneously. Wow, that's great! I don't think I've had ter'angreal 100% working in MSVC for a long, long time. At some point after the dust clears I'll have to sort through all my mad hacking and figure out what I actually did to make it work... actually it wasn't quite that bad. But there were a few interesting things along the way, such as: - A bug in wxwidgets' msw/main.cpp where it used WXMAKINGDLL instead of WXMAKINGDLL_CORE (I'm guessing they've fixed this by now) Well that sucks. We have our own wxwidgets branch so we can fix that, though. - Adding CS_NO_NEW_OVERRIDE to the CS setup file -- their special debugging new/delete stuff was just causing too much trouble and I didn't want to figure out exactly why. That's fine, we arn't going to use their memory debugging anyhow. - having to track down a weird bug in object movement that seemed to have something to do with snprintf... That last one is worth talking about here -- my avatar movement was all wonky. But now that i have an IDE debugger that actually works decently, I was able to trace the problem to snprintf printing the floats wrong for position/oritentation in the 3dobject properties in some cases. It was using the custom snprintf function, but I didn't actually identify where in that function the problem lay. Instead I just went ahead and made it use _snprintf (just like MinGW)... is there any particular reason not to use _snprintf? The microsoft headers define it... Uh. Yea, I don't know why I did that, aside from the fact that fighting with Microsoft's idea of what is and is not in the standard library is an endless source of frustration. We should probably have just used #define snprintf _snprintf, then? Anyway, just throught you'd be interested. I haven't tried building the new demo server yet, but when I do I'll see if I can track down that crashing bug (unless it's been fixed). I did go ahead and walk around the new gallery COD in local-file mode in terangreal, and it's pretty spiffy. The solid camera, even as simple as it is, is a nice addition, too. Oh, and grabbing things is fun :) (However, I can't actually log in to the interreality server at the moment... ) I need to pull out the ircbridge plugin from the interreality.org configuration until I can figure out why it's causing the server to deadlock. What's irritating is I haven't been able to get a stack trace that will tell me exactly where the two deadlocked threads are getting stuck, so it's been exceedingly hard to debug. (I'll do that right now, so by the time you get this message the world should be back online.) -- [ 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
Re: [vos-d] Integration of VOS and IRC
Yes, the IRC plugin is included as part of the distribution by default. It creates a VOS user for each IRC user in the virtual world, and creates a separate IRC client session for each user in the VOS world, so it is completely transparent. Currently IRC users in VOS arn't given any form, but there's no reason why they couldn't be given avatars and placed somewhere on the map (I someone suggested having them wander around aimlessly, like the townspeople in certain console RPGs :-) Also something I've wanted to explore is the possibility of creating a semantic representation of a space that is meaningful enough to be navigated from both a MUD-style text interface, while still being able to enter it as a fully 3D immersive world. You could lay down a node network of positions where the text-user could go, add descriptions to all the objects in the space, and then at each node it would print out the descriptions for things that were nearby. For example (thinking of the current demo black sun world: --- You are standing on a hill of brown dirt. To the north is a large white pyramid with an entraceway. To the east the hill continues. To the west the hill continues. To the south is black nothingness. $ Go north You are at the entrace to the Pyramid. To the north is a hallway with a tiled floor. At the end of the hallway are ramps leading up and to the east and west. To west is a doorway. $ Go north You are at the end of the hallway. To the south is the entrance to the Pyramid. To the west is a doorway. Up and to the east is a ramp. Up and to the west is a ramp. Gonzo is here. Gonzo(3d) says Hello! Gonzo(3d) goes south to the entrace to the Pyramid. You see Gonzo(3d) by the entrace to the Pyramid. Gonzo(3d) waves to you. $ --- And so forth... On Tue, Apr 17, 2007 at 04:54:36PM +0100, Marcos Marado wrote: Hi there, I said this on your IRC channel... - * Now talking on #vos * Topic for #vos is: Virtual Object System :: http:://interreality.org :: Free Multi-user Virtual Reality * Topic for #vos set by tetron|mac at Tue Dec 12 04:28:20 2006 * #vos :[freenode-info] why register and identify? your IRC nick is how people know you. http://freenode.net/faq.shtml#nicksetup Mind_Booster_Noo hi there * You are now known as Mind_Booster Mind_Booster I saw your website... Mind_Booster I wonder, does the VOS server already comes with this plugin to interconnect a world with IRC? Mind_Booster I'm a talker owner (for those now knowing, a talker is a text-based virtual world) and it would be great to be able to connect it to a graphical world like VOS Mind_Booster keeping both interfaces, the via telnet text-based world and the vos-browser... Mind_Booster hmm, I guess you're all asleep :-P Mind_Booster I guess I'll email this question to the mailing list :-) Mind_Booster thanks anyway, and keep up with the effort :-) - Can anyone please give me an answer? I would really be interested in this. -- Marcos Marado Sonaecom IT ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] s5 concurrency (design part 2)
On Thu, Apr 12, 2007 at 10:41:40AM +0200, Karsten Otto wrote: I thought that the coroutine stuff applied trusted code only - after all, when you cross the border to untrusted code, you have to pass control over to whatever virtual machine executes it, and hope for the best. In the most general case, this virtual machine might use a different threading model or may not even *have* threads (shell script?). Changing arbitrary kinds of script code on the fly is bound to be difficult, error prone and time consuming. Modifying all VMs to support context switching is even more unrealistic. Usually people only have a standard perl/python/lua/xyz installation. LL has the advantage that people only use ONE scripting language, running on ONE VM - under their control. The point of the Second Life example was that it has been shown in practice that it's possible to implement cooperative multitasking in a way that still doesn't allow unscrupulous users to hang the system (at least not with naive attacks like going into an infinite loop). This is important, because preemptive multitasking is difficult and generally non-portable to implement in userspace; it is the job of the underlying operating system to provide multitasking facilities (processes, threading). The problem for VOS is that these facilities are probably too heavyweight for the number of simultaneously executing actors that we want to be able to scale up to support. In the case of LSL I believe that the client compiles the scripts locally and just uploads the bytecodes. It uses the CLI run on the .NET virtual machine, and they've been making noises about supporting C# (although it may be that LSL uses a restricted subset of codes that are easier to verify, which would not be the case for C#). So they are doing static analysis and modification on the actual bytecodes to be run. So you're right, it requires targeting a specific virtual machine platform, but there's nothing wrong with that. I'm not suggesting this for scripting in general, but for the particular case of mobile code (downloaded to the client or uploaded to the server and executed automatically) where it is necessaray to provide a constrained, secure environment. A pretty fundamental aspect of security is not being able to hijack the host application's computation. -- [ 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
Re: [vos-d] s5 concurrency (design part 2)
On Thu, Apr 12, 2007 at 08:13:19AM -0400, Reed Hedges wrote: OK. (You could use VOS easily to do flow based programming, I think there's a brief note about this in the wiki somewhere.) Yes, of course. I think the actor model is much more general-purpose, at least in so far as it seems much simpler to describe flow-based programming using actors than to describe actors using flow-based programming. I was under the impression that an Actor was a function that did just one thing? Or are there variations on the model? Did you read the Wikipedia article? An actor is an independent concurrent entity which can exchange messages with other actors, create new actors, and designate the behavior for each message received. -- [ 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
[vos-d] terangreal changes
This is mostly directed at Reed, but I thought everyone might be interested -- In working on a virtual demo world/presentation (which I intend to use as a more compelling alterative to openoffice impress slides in presenting VOS to potential investors) I've made a few changes that make worldbuilding much easier: - Fixed bugs in blender export script which causes rotations to sometimes come out wrong. - Added an addtype directive under the load section in XOD files, so objects from loaded files can be extended. - Added some code to the vosapp framework so that if plugins introduce new metaobject factories, existing vobjects with that type will have metaobjects automatically attached. - Fixed some collision handling in the CS plugin that was misbehaving. - The 3rd person chase camera now won't go through walls, but will zoom in as necessary to have a clear line of sight to the avatar. - If you can hit g while moused over a 3d object, you grab it, this means the object is placed in front of you and moves around when you move. (Moving this with the mouse isn't supported yet.) You can tag this a3dl:nograb to tell ter'angreal not to grab them (useful to avoid grabbing the floor or walls by accident.) So, in combination with the new misc:clickable and misc:textentry types (which communicate clicks on prompt for text on 3D objects) it's now relatively easy to add behaviors (written in C++) to 3D objects in scenes created in Blender. See galley.xod in vos/apps/omnivos/ for the work in progress. -- [ 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
Re: [vos-d] s5 concurrency (design part 2)
On Thu, Apr 12, 2007 at 08:56:12PM -0400, Reed Hedges wrote: Will messages be like they are now, essentially a map? Or could we have a Message subclass generated from the OTD, with pointers into the message data for each field, so we don't have to look up fields by name each time? We could do that, although actually as implemented in the current s5, the fields are converted into arguments to a method, so the user doesn't see the actual message structure, just gets a method call with the fields as parameters. This is why type conversion to the expected method signature is important. Yeah, it would be nice not to have to do too much processing on the Message object to send it out over the network-- just grab a data buffer out of the object and byteswap it (or not). Some processing is necessary if messages are to remain abstracted from the concrete serialization format. In particular, it ought to be possible to convert a VOS message to both a lightweight binary format or to something like SOAP or XML-RPC for interoperating with 3rd party systems. That's where having both a binary encoding and ASCII encoding for primitive types comes into play. One thing that would be nice in s5 is to be able to very easily nest message structures, either through just embedding a second message inside another as a field, or by a struct definition in the OTD and putting struct type data in the message. Actually s5 has structs already! As it stands now it is fairly weak (only combinations of primitive datatypes or other structs allowed, no recursive nesting, no dynamic-sized arrays) but I certainly agree that structs are useful. Here's some testing code in the current s5 interface. This is real interface code which can be processed by the code generator: interfaces namespace name=a3dl struct name=vector3 field name=x type=float / field name=y type=float / field name=z type=float / /struct struct name=rotation field name=axis type=vector3 / field name=angle type=float / /struct class name=object3d child name=position type=vector3 / child name=orientation type=rotation / child name=transform-group child type=object3d count=any / /child /class /namespace namespace name=misc class name=talkative child name=relay-listeners child type=talkative count=any / /child method name=say param name=text type=string / param name=scope type=uint16 / param name=priority type=uint8 / param name=in-reply-to type=uint32 / /method method name=resend param name=resendTo type=vobject / param name=text type=string / param name=scope type=uint16 / param name=priority type=uint8 / param name=in-reply-to type=uint32 / /method /class /namespace /interfaces -- [ 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
Re: [vos-d] s5 concurrency (design part 2)
On Wed, Apr 11, 2007 at 06:20:21PM +0200, Karsten Otto wrote: Ok, I get it. What you say sounds exactly like the Simula coroutine concept, where you use an exchange jump to switch between multiple stacks. This is not necessarily the same as user-level threads, in particular when blocking I/O is involved. You're right, it's a bit different from user threads, although what I have in mind could be handled reasonably well by creating a user thread for every vobject ahead of time. Then a sending a message would involve more or less pushing the call into the target's message queue and then explicitly yielding to the target. However, I realized after writing the email that that any solution which results in blocking the sender due to the target blocking isn't the right behavior. The sender may be able to handle the message as an asynchronous call (since it gets a future back) so it's not fair to block it -- indeed that's the whole point of being able to switch tasks. So, we want to be able to save state and return to the immediate caller (not the toplevel event loop, as I said in my previous email). Unfortunately the unix swapcontext() isn't really appropriate in this case, because it saves the entire stack (which includes the caller's stack, and caller's caller's stack, etc...) and we're really only interested in just the stack for the current vobject. Digging around a bit I found http://en.wikipedia.org/wiki/Coroutine which explains this nicely, lists a few libraries, and even mentions the Actor model (duh) :-) You probably know this page already, but I thought I'd mention it anyway just in case. On further research, I'm coming around to the conclusion that there simply doesn't exist a good implementation of coroutines or user threads in C/C++. So I think a futures-based, continuation-passing style is going to be the way to go, with blocking waits not permitted. Instead, we'll focus on the more tractable goal of providing a good API for psudeo-continuations in C/C++ (boost may be helpful here) as well as hopefully ensuring that design allows bindings for lanaguages that do have coroutines/continuations can take advantage of it. I should also note that the other side of this is that a method can be marked CPU_INTENSIVE or BLOCKING, which will cause VOS to always execute the method in a different thread from the sender. The goal of all of this is that, since we will be doing message passing internally to the application and as well as across language/network boundaries, to be efficient and avoid context switch overhead when the method being called is trivial. On a related note, I started thinking a lot about user threads/microthreading/continuations etc in part from reading a couple of developer blog entries on how Linden Labs acomplished it in their server. They have an interesting challenge (which we will eventually also have to deal with) which is that they need to support many thousands of scripts running simultaneously on a simulator, and the scripts come from untrusted sources that can do obnoxious things like spin in an infinite loop and never return. Operating system threads arn't suitable due to overhead (and possibly also due to synchronization requirements with the physics simulation) so it has to be a user-level thread strategy. However, users can't be trusted to have their code ever yield (or even ever end). So, they force the issue. The scripts are compiled for the .NET virtual machine, but before they are allowed to run, a gatekeeper inserts explicit yields into the bytecode at strategic points (branching points being the obvious target, if I had to guess). This results in each script periodically checking to see if it has run out its timeslice, and when that happens it explicit yields to the next thread without the need for preemptive scheduling. -- [ 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
Re: [vos-d] s5 concurrency (design part 2)
On Tue, Apr 10, 2007 at 10:52:33AM +0200, Karsten Otto wrote: Ok, I haven't studied this Actor model so far, let me see if I understood it correctly. Note that what I'm proposing here is an elaboration on the model -- a literal implementation of the model would put each actor in a separate *process* and compel all communication over sockets (this would enforce the no-shared-state aspect of actors). However, even on modern operating systems, having 10,000 vobjects as 10,000 separate processes is not going to be efficient, so we need to allow the implementation to take shortcuts. If a message comes in from the network, you determine its target vobject and method(?). You then try to bind/lock the target, and execute its method in a thread you pick from a pool. If the vobject is already bound, you just queue the message for later execution. Once the vobject gets unbound/unlocked, you pick another thread from the pool and pass the queued message to the target method. (Actually, it does not matter whether the message came from the network or some other actor, which is neat). Right. The goal is to unify message passing so that it genuinely does not matter if a vobject is local or remote or native code or a script. I'd also like to support transparent process migration, so that a vobject could move to another host and have its messages forwarded to it. The trick is support all this AND still be efficient and easy to use. While a vobject method is executing, it can send messages to other vobjects, which either bind and execute the target *in the same thread* or queue a message, as before. In the latter case, you get a future you can query for completion or wait on. The purpose of allowing execution within the same thread (when the target vobject is unbound) is that usually the actual method handler code that needs to be executed is either small and quick to execute, or the caller is likely to block anyway (in the case of reading a property) so there is less overhead if we just service the request immediately. For the cases where a call is likely to start a long-running process, it is the responsibility of the programmer (of the method handler implementation, not the caller) to mark these methods as such so the system knows to spin them off into a separate thread. Assuming I got it right so far, I wonder what happens if you decide to wait on your future. When you do this, you block the current thread, which nevertheless still holds the locks of / is still bound to one or more vobjects. In other words, the deadlock just waits around the corner - e.g. two vobjects with separate threads and futures for each other. Or does waiting automatically release the blocks/bindings? In that case, what happens once the thread unblocks? And can another thread bind/lock the vobject in the meantime? This is a good point; blocking makes everything more difficult and when I was writing about it originally hesitant to include it at all. Now I see my instinct was correct. The two solutions I see are: - Disallow blocking, and require a continuation passing style where futures+callbacks are chained together and returned up the stack to the main event loop, at which point it is added to the scheduler to be executed when the commitment is either satisfied or fails. - User-level threading on top of OS threads. A blocking call would save the stack and return to the main event loop (using swapcontext() or the Windows equivalent), at which point the (user-level) thread is added to the scheduler to be resumed when the commitment is either satisfied or fails. If this sounds similar to the first case, that's because it is. The key difference here is that it requires less work on the part of the user (less boilerplate, code doesn't have to be split up across methods). The disadvantage is that users may be less aware of what is going on, and that other methods could be called while their handler is blocked. In either case, when a vobject chooses to wait for a result, that vobject and all the vobjects in its call stack would be permitted to service other requests. This solves the problem you present: the 2nd vobject in the 2nd thread is eventually able to call the 1st vobject, because the 1st vobject has yielded control and can handle new requests. I should also note these two options arn't incompatible, so there's likely no reason we can't have both continuations and user-level threads. My preference is towards cooperative threads, however, unfortunately portability is going to be difficult as Linux, Windows and OS X all seem to use different APIs for this. I haven't yet found a library that abstracts it across operating systems in the same way that has been done for OS threads. Most portable user-level thread libraries I have found actually use setjmp/longjmp, which doesn't preserve the stack. -- [ Peter Amstutz
Re: [vos-d] s5 concurrency (design part 2)
On Fri, Apr 06, 2007 at 05:16:16PM -0400, Reed Hedges wrote: There's also something called Flow-Based Programming that is similar. In some ways it's closer to VOS since Actors are, I think, more like method handlers (in VOS terminology). I don't agree. Flow-based programming is very data-centric, in the sense that it views the system as a connected chain of inputs and outputs and black boxes doing transformations. This is a good fit for certain kinds of data processing where data is streamed through a multistage system (audio/video processsing, certain types of batch processing) but isn't as useful for interactive systems. If each box in a flow programming system is a vobject, and a connection between boxes means sending a message between vobjects, VOS starts out with the assumption that every box is potentially connected to every other box. At that point the flow model isn't particularly useful. VOS grew out of my work in multiagent systems, and it's pretty well understood in that field that agents act independently of one another and their communication/coordination is asynchronous. Thus, the idea that vobjects == actors seems like a natural fit. You could say that the actor model is a design pattern that we happened to stumble upon, and that by recognizing it as such we can take advantage of the existing work on the topic. But Actors Model is more well known and more carefully studied and defined (though I guess we will be deviating from it) Well, it's a model, not a precise specification. The basic goal here is to define how flow-of-control works in a concurrent VOS application, in a way that is easy for users to grasp and prevents deadlocks and race conditions. -- [ 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
Re: [vos-d] misc:search questions
On Sat, Apr 07, 2007 at 04:56:53PM -0700, Ken Taylor wrote: So my voyages through the VOS codebase have brought me to the misc:search metaobject. It's a pretty nifty metaobject, really... but i have some questions/comments: - It looks like when you acquire an object, some times it will also acquire all that object's children. I'm specifically looking at the CatchUpdatesFilter::savechildren value. But I don't quite understand in what cases this gets set and what the rationale is for getting the children. All the message filtering stuff makes the code a bit hard to understand, because the filters happen in the background and change the normal behavior of the VOS system... the fact that you guys seem to be allergic to comments doesn't help either ;) (i jest! i jest ... sorta) The basic theory behind the search metaobject is that it has a pattern-matching state machine that walks the vobject tree, synthesizes queries to each vobject, and catches the responses (hence the filter). The responses are the packed into a COD, gzipped, and that is transmitted to the client which does the process in reverse. This is what allows VOS to have a fine-grained representation of the world yet still download it relatively quickly and efficiently. That said, I haven't decided whether to keep it for s5 or do something else that might be simpler. It's arguably overkill, and the complexity means it may be hard to optimize. Also it needs to accomodate some design for caching, where the client might send a set of hash codes describing its cached data, and the search object has to be smart enough to only send the parts that have changed. (man, i'm just a complainer, aren't i?) Reed is right, I don't comment my code enough. I'll try to be better about it in the future, especially since I know more people are looking over my shoulder now. Also: you should be REALLY thankful you didn't see the first version of the search metaobject :-) - Could it be possible for there to be a malicious or just buggy infinite-loop query that messes up the server (since incoming update messages are being deferred during a query), or is it guaranteed to terminate? As each vobject is visted, a temporary flag is set to prevent it from being processed a second time, so it won't get stuck on cyclical links. - Should there be some sort of access control ability on the search node, limiting who is able to initiate a search? - Could the search node be used to get around property deny all access control in some cases, and return the forbidden data anyway? The search is done with the identity of the requester, so while it may be possible that someone could attempt a denial of service attack by issuing multiple searches, it should not enable them to access data they wouldn't be able to access otherwise. -- [ 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
Re: [vos-d] bakefiles
On Wed, Apr 04, 2007 at 07:38:11AM -0400, Reed Hedges wrote: Well, automake works fine for me in general on MinGW whenever I've used it there, but never tried it with Visual Studio or Cygwin. Of course there's always the incompatible-versions problem with the autotools. And maintaining a ton of visual C files sucks, I have to do that all the time :) Well automake essentially works, the real bastard on mingw and cygwin is libtool. Unfortunately you can't really use automake to build DLLs without libtool, at least not without a lot of hacking. My main beef with automake itself is that it doesn't have good mechanisms for applying rules across the whole project (so we end up with the inplace boilerplate at the bottom of every file) and recursive makefiles suck for parallel builds. It's not worth fighting with any more, and since we're going to be doing a lot of rewriting from scratch in s5, we might as well reboot the build system as well. That's good. If we can keep those project/make files in the tree without too much trouble then that would be an ok way to go. Let's also keep the bakefile source in the tree and in the source release too, especially if eventually we want vos to be buildable on all kinds of server operating systems (and where admins want to just run make and not have to install extra tools). Before settling on bakefile I still need to get an idea of the strengths and weaknesses of the Crystal Space build system (Perforce Jam), Boost.Build (Boost Jam) and Scons. Essentially bakefile is a meta-makefile more like automake but more abstract (and thus able to target a variety of underlying build tools), whereas Jam and Scons are full make replacements. I still need to determine what specific unique features Jam and Scons offer that might tip the decision in their favor. Incidentally, it's probably possible to write a bakefile backend to produce Jam and Scons files ;-) -- [ 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
[vos-d] s5 concurrency (design part 2)
in the vobject's queue and executed later. All method calls with present only an asynchronous interface. The call will return a future (also known as a promise in the E language) which is a handle representing the progress and outcome of the computation. The caller can then do a number of things with it: - ask if the computation is completed - block until the computation completes - block until all results are known for a set of computations - get the result, if completed - get the error, if failed - get the progress of the computation - register a continuation to be executed when the computation completes - register a continuation to be executed when all results must be known for a set of computations - register a continuation to be executed every N seconds when progress has occurred I anticipate that the preferred pattern will be to pipeline as many requests as possible, return to the caller, and later handle the results in continuations (essentially callbacks) as they come in. This permits very lightweight, interleaved execution even with thousands of actors. Something I'm contemplating would be the use of user-level threads (using make/swapcontext() on Unix, and either get/setThreadContext() or the fibers API on Windows) when calling the blocking calls above. This would simplify user code a lot, as the user would not need to manage context and could avoid splitting an algorithm across function bounderies (which might otherwise be necessary to ensure that that control flow resumes in the proper place.) The last thing I want to talk about here is transactions. Because vobjects are relatively fine grained, there will be cases where it makes sense to do a read-modify-update action on several vobjects at once without anyone seeing the intermediate results. To this without the possibility for deadlock will probably require a centralized lock manager, but otherwise seems straightforward: bind a set of vobjects to a particular actor, checkpoint their state (for rollbacks) and disallow outgoing messages to objects not part of the transaction that could change anyone else's state (like change notifications) until the transaction is completed. With a proper model for expressing these state changes, we could develop more general change tracking into a version control capability. I think that about sums it up my current thinking on concurrency. There's a couple of other things I'm mulling over (process migration being one) but for the most part I believe what I've outlined here consists of a pretty thorough runtime/concurrency model that hopefully hits the sweet spot of power, ease of use, ability to scale across multiple cores and processors, and ability to interface with non-threadsafe code. Finally, the pure message passing/actor model greatly facilitates cross-language method calls (scripting!) which I will discuss in my next s5 design email. -- [ 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
Re: [vos-d] Flux Worlds Server Announcement
On Mon, Apr 02, 2007 at 09:26:59AM -0600, S Mattison wrote: The TerAngreal browser, I feel, doesn't serve as an integrative metaversal tool; because it uses proprietary OS-GUI-interface system calls, to generate the 'chat area' as well as the 'user list', and even the 'menus'. Well ironically, the point of that is to serve integration with the user's desktop. For various reasons, 3D-based GUIs tend to be clunky, due either to lack of polish (the GUI hasn't had the years of development attention that say GTK has), lack of integration with the desktop (things like cutting and pasting doesn't work like the rest of the desktop, if it works at all) or simply being slow (because the GUI is rendered on top of the 3D scene, the update rate of the controls is throttled to that of the update rate of the 3D scene as a whole.) Thus, the use of WxWidgets to create a native look and feel was a deliberate design decision, not because it was easier (because it's not, it actually makes some things a lot harder.) -- [ 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
Re: [vos-d] bakefiles
On Sun, Apr 01, 2007 at 09:28:41AM -0400, Reed Hedges wrote: Is it really bad enough to throw out our investment in the autotools configuration? bakefile is probably the most obscure of all the build Whenever I try to set up a VOS build environment on Windows, I get a sharp, throbbing headache and a strong urge to throw my chair out the window. It's difficult to understate just how big of a maintainance hassle the current build system is on Windows (whether Cygwin, Mingw or Visual Studio). It's so bad that I've seriously considered creating a tarfile of the entire mingw tree on interreality.org as the recommend way of setting up a VOS build environment. It takes me personally several days of fiddling to get ter'angreal to build and work on Windows on a new system. Automake is lovely on Unix, but it is an awful cross-platform build system where the platform is not a unix variant. Notice I didn't say anything about autoconf. I would venture that we've probably invested more time in autoconf macros that automake hacks, and that autoconf is not the problem here, it's automake and libtool. tools you list. If you do switch to bakefile, let's keep some Makefiles in the bzr tree. And keep bakefile inside the bzr tree so that you don't have to have it installed if you want to modify the makefiles. I know, bakefile is a little obscure, however it appears to have grown out of the needs of wxWidgets, which means it's already been proven to work for a large, complex multiplatform project. The primary advantage of bakefile vs. jam or scons is that it generates actual project files for various compilers, so users don't have to drop down to the command line to build VOS when everything else they are doing is in the IDE. I'd suggest looking into scons, since it seems to be more popular than bakefile (it's also used by blender). I have never used it though. Would jam be useful for generating VC projects or nmake files too? While Crystal space does have the ability to generate visual studio files from its Jamfiles, it does so via a lot of extra jam rules and a perl templating system, so it's not easy. That said, adopting the (jam-based) Crystal Space build system as a whole may be worth looking in to. Finally, I guess I really should try out scons. -- [ 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
Re: [vos-d] Spam on wiki
I know, it sucks, I was deleting some of it last night. I turned on the spam blacklist feature of MoinMoin (which had gotten turned off in the move from the old server to the new one) so maybe that will help. I'm not sure if MoinMoin has a revert feature. Need to dig into it more. On Sat, Mar 31, 2007 at 02:08:30AM -0700, Ken Taylor wrote: A bunch of spam got added to the wiki between 3-25 and 3-27... I don't really know much about MoinMoin, but do you guys have a way of mass-reverting stuff like this? Ken ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] bakefiles
I'm considering switching the VOS s5 build system from automake to Bakefile (http://bakefile.org). The reason is that the maintainance overhead imposed by automake has started to get annoying, and that automake provides no support for building outside the conventional unix toolchain (for example, using Visual Studio). The main recommendation for Bakefile is that it is used to by WxWidgets, which is a project with critical need for a cross-platform build system if ever there was one. Bakefile is similar to automake in that rather than actually running the compiler itself, it is a sort of meta-makefile that is compiled to produce the actual makefile which does the actual work. Unlike automake, bakefiles are designed to be retargeted to produce project files for a number of different build systems -- the big one for us being Visual Studio projects. One thing that has impressed me about the bakefile system is that it has a target designed specifically to be integrated with autoconf (it produces Makefile.in files), so we can still do all the usual feature tests to configure the build to a specific platform. Also, unlike a full build tool like Jam, due to bakefile producing files for the native build system, developers are able to build from source distribution without actually needing bakefile. Does anyone have suggestions for other build tools I should consider? Other ones I can think of offhand are jam, bjam, ant and scons, all of which annoy me at some level (except for scons, which I haven't used.) -- [ 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
Re: [vos-d] s5 design overview
guys are going to be focusing on the issue from the ground up. My goal for s5 is to be able to support one million vobjects on a single site, on reasonable hardware. We'll be doing benchmarks. -- [ 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
Re: [vos-d] How to host a product design dinner party
Check this out: http://earlystagevc.typepad.com/earlystagevc/ The most recent post about Web 2.0 talks about how he thinks the next big thing is going to be interoperability. He mentions it more in the context of web services, but in fact many web services are a step backwards in terms of transparency, as a monolithic function-call API reveals little about the underlying structure of the data you are querying. VOS as a platform for interoperability has a lot of potential. What's unique, I think, is we're concerned with interoperability on multiple levels, thinking outside the web (HTTP/HTML) box, and application focused, so instead of fuzzy-headed theory or design by committee but we're actually trying to make it work for us in practice. Walking into a presentation and saying A focus of the VOS platform will be on interoperability with existing systems makes people ears perk up, probably because the strategy for 99% of systems is platform lock-in. Since we're open source, we have no motivation to create lock-in, and ironically lack of lock-in becomes our own advantage. Also, last night I came up with a new analogy for VOS: XML for Objects Meaning, essentially, in the way that XML provides a meta-syntax for documents and enables a galaxy of tools and applications that can process them, VOS could provide a meta-framework for applications to interact, and similarly enable a galaxy of tools and applications that can interoperate with them. On Tue, Mar 20, 2007 at 11:13:09AM -0400, Reed Hedges wrote: http://headrush.typepad.com/creating_passionate_users/2007/03/how_to_host_a_p.html -- [ 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
Re: [vos-d] How to host a product design dinner party
On Wed, Mar 21, 2007 at 04:07:10PM -0400, Reed Hedges wrote: Walking into a presentation and saying A focus of the VOS platform will be on interoperability with existing systems makes people ears perk up, Right, though that's a hard thing to promise. Maybe we're willing to make VOS interoperable with other systems as required, and here are a few we've already done: x, y, z. To add the it's-not-cookie-cutters part: you can organize your data in whataver way fits with your need, and while this requires a bit more work to actually do that, all the features and tools and other automatic bits will still work. It's true. The advantages to VOS seem to be that it gives you a have-your-cake-and-eat-it-too approach to data structures; you can smoosh several data models together into the same logical object on the fly. Among other things this means that you can avoid slicing whereby data specific to one data model is lost in translation because the target data model doesn't support it and doesn't have room for it. In the VOS case, you translate what you can into standard object types, but can also attach your extended data and leave it there until you need it later when writing out the data to the original format. Now, this isn't perfect (there could be data dependencies which arn't maintained if the standard data is changed without updating the extended data) but it's light years better than what most people are doing. Also, last night I came up with a new analogy for VOS: XML for Objects Meaning, essentially, in the way that XML provides a meta-syntax for documents and enables a galaxy of tools and applications that can process them, VOS could provide a meta-framework for applications to interact, and similarly enable a galaxy of tools and applications that can interoperate with them. It's an OK analogy but only if you don't then start applying assumptions to VOS based on what XML is for and what it's restrictions are. Right. I'd only use this analogy with someone who already has a vague idea that VOS is about communicating objects and not documents. -- [ 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
Re: [vos-d] http://research.sun.com/projects/darkstar/
It's potentially interesting, although the details seem a bit thin at the moment -- there doesn't seem to be any obvious documentation on its architechture. It's also non-free software (in the GNU/FSF sense) which is a drag. On Thu, Mar 15, 2007 at 08:53:19PM -0700, HEBLACK, J wrote: http://research.sun.com/projects/darkstar/ Should the page above be checked for the release or is that not something of use here? Project Darkstar is a research effort focused on the design of massive-scale, latency-optimized systems like online games. Written entirely in the Java programming language, the server platform provides a simple but powerful interface for defining server-side application logic. It takes care of persistence, load balancing, consistency and communications, leaving developers free to focus on their applications. -- Entrante.fir Search name: excremento Find items: If any criteria are met Sender contains unclean Recipients contains unclean Subject contains unclean Message Body contains unclean Source Account is HEBLACK, J [EMAIL PROTECTED] Then Move to Folder Inbox/Air alert ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] VOS making Moneys.
I think what you're getting at is that we should take a broader view of what VOS could be -- and I agree. The potential influence of VOS is similar in scope to that of the world wide web, and I'd like to make sure we get it right. However, I'd also like to submit that interoperability is a key bridge that will enable people to cross over from the systems they are using now to our eventual VOS-based systems, so we need to consider the needs of existing platforms. We also can't and shouldn't try to do everything, in particular so that we leave space for other people to be able to come in and experiment with their own ideas. Conversely, it's also important to identify what existing systems are pretty good, and worth building on. OS kernels (Linux) are pretty good. 3D engines are pretty good. Databases are okay (object databases seems to be a weak area). GUIs are okay (we're in the midst of a slow paradigm shift away from raster graphics towards vector graphics). There are many many interesting programming languages on the fringe that are worth learning from. Computer security is so awful it's definately worth looking at systems that ARE considered secure. I don't know much about what investors want to hear, but a boil the ocean type of project to reinvent computing doesn't really seems like it brings enormous risk with it. It's one thing if you are giving a grant to some fuzzy headed academics, but for VOS we're trying to straddle both computer science and practical software engineering. Hence the present focus on a relatively specific end product. One thing I'm learning about presentation is that you need to have big ideas, but you also need a meticulous development plan to get there. The devil is in the details! On Tue, Mar 13, 2007 at 05:54:51PM -0600, S Mattison wrote: Ah, true. But what sets this apart from the other interactive 3d world softwares out there? There are so many other communities, communities with names for themselves, why should I invest in VOS? This is what the investors will say. How does VOS stand apart from the crowd? What do I get in return? I'm not sure I fit in with a community of Linux Geeks. Well, unless you find a linux-oriented investor. I'm not saying it's impossible. I'm just saying that I have an idea that might make the idea a lot more appealing, and I know some people who can help set it up this way... That will get us to Step 2, which is to go for more significant investment funds and build a company that can capitalize on the platform more directly. Then we sell VOS services far and wide, show up on the covers of magazines, and hopefully make it to Step 3 :-) So, you want to know my idea by now, and some of you may already have guessed... (Especially those who know me, or have payed attention to my previous rantings...) I propose we take VOS, and recode its back-end architecture to run just a little bit closer to the hardware, and add a software-rendering option. Give it power over various filesystem commands by using simple filesystem descriptor plugin-files. Give it the ability to access myriad protocols, to fill 3d objects with various online 1d and 2d content. Give it, also, if you're still with me, the ability to intercept, interpret, and render the window and terminal functions that are called by normal ELF binaries and drivers, as though these programs were actually running inside VOS itself (perhaps with their own descriptors so as to eventually support binaries from other OSs!). And for the final step, give it it's own hardware drivers, and create bootloader entries that call this program into it's own kernel mode! At that point, with these things: Specialized rendering, Filesystem access, Protocol access, and Parenting other processes, what need is there for any other Windowmanager? Since you can design your own interfaces within VOS, and create objects that, with a single click, hardlink/shortcut to open locations within protocols or filesystems, you don't need KDE, Gnome, or any other windowmanager. Since the descriptors are in place, there would be an open architecture to expand support for new filesystems, as well as child-binary emulation support, perhaps more advanced than WINE, since it aims at more than just Windows. -- [ 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
Re: [vos-d] http://research.sun.com/projects/darkstar/
The Inquirer article mentions the GPL but I can't find any indication of licensing terms on Sun's own Project Darkstar page, except for the SDK download which appears to be a very restrictive non-commercial license. They say open source right on the first page, but I can't find any indication that they actually mean it. On Fri, Mar 16, 2007 at 09:27:49AM -0700, HEBLACK, J wrote: On Fri, 2007-03-16 at 09:57 -0400, Peter Amstutz wrote: It's potentially interesting, although the details seem a bit thin at the moment -- there doesn't seem to be any obvious documentation on its architechture. It's also non-free software (in the GNU/FSF sense) which is a drag. Well here is maybe a better vaporware article which talks of darkstar in terms of GNU and C++ and assembly wrappers: Sun talks about Darkstar cunning plan http://www.theinquirer.net/default.aspx?article=38137 -- [ 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
Re: [vos-d] XOD questions
My basic complaint with X3D was that the transition to XML could have been an opportunity to clean up a lot of the syntactical warts of VRML (delimiting index face sets with -1, for example) while still keeping the basic data model. We could have had a schema that follows the best practices for XML document design, follows XML data types, etc and would have been a breeze for developers to support. Instead, they choose to do a translation that amounted to little more than replacing curly brackets with pointy ones. Having written a minimalist X3D loader (just geometry) it irked me that I had parsing issues -- Parsing Issues, in XML! -- between files produced by two different programs because of the extra syntax embedded in CDATA that wasn't part of the DOM structure. I'm not saying it doesn't work, it is primarily an aesthetic issue -- but it does cause headaches for developers. On Thu, Mar 15, 2007 at 10:36:11PM -0500, Len Bullard wrote: Be fair, Peter. It is the X3D instance you have to import, not the schema. The schema is baroque to put it mildly. I'm not sure if it is used for import. BS Contact has a validating switch, but I've not tried it. The schema is useful for the x3d-edit utility, but even then, not too many peole edit graphics like a document unless the are already very familiar with the tree. len -- [ 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
Re: [vos-d] http://research.sun.com/projects/darkstar/
Ah, you're right. So they are *going* to make it open source, but arn't quite there yet. But it's good to hear. It looks like Darkstar is mainly (exclusively?) a server-side technology, so it doesn't go quite as far up the application stack as VOS is targeting. In other words, it doesn't address the browser question. I am looking forward to their GPL release, though, since they are pushing the application high availablity/high reliablity and load balancing technologies and I'd like to learn about their architechture. On Fri, Mar 16, 2007 at 10:48:16AM -0700, HEBLACK, J wrote: On Fri, 2007-03-16 at 13:31 -0400, Peter Amstutz wrote: The Inquirer article mentions the GPL but I can't find any indication of licensing terms on Sun's own Project Darkstar page, except for the SDK download which appears to be a very restrictive non-commercial license. They say open source right on the first page, but I can't find any indication that they actually mean it. Here is the chief architects blog(Mar. 7) about that Sun Labs East picked it up: Darkstar goes Open Source and other updates- http://blogs.sun.com/gameguy/entry/darkstar_goes_open_source_and The Open Source model is ideal for the small developer. Build your product. Start making money. And then, when you have income, hire the authors of the technology you are based on to support that enterprise. Its a no front load scheme which is ideal for those with talent and creativity but not a lot of cash. -- [ 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
Re: [vos-d] Typo in sector.cc
Good idea. This is what distributed version control is good for. While
you're at it, you can fix that synqueue.cc bug you pointed out, because
I haven't gotten around to it ;-)
On Fri, Mar 16, 2007 at 08:38:58PM -0700, Ken Taylor wrote:
In libs/vos/metaobjects/a3dl/sector.cc:
void Sector::setCollisionDetection(bool enabled)
{
Property::setProperty(*this, a3dl:colision-detection, enabled);
}
bool Sector::getCollisionDetection()
{
bool b;
Property::getProperty(*this, a3dl:colision-detection, b);
return b;
}
collision is spelled wrong...
Maybe I should make a bzr revision bundle so i can get my name in the log ;)
-Ken
___
vos-d mailing list
vos-d@interreality.org
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
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Typo in sector.cc
You can send it to me and Reed. Or, alternately, you can publish your
branch somewhere and I can merge it.
On Fri, Mar 16, 2007 at 08:59:58PM -0700, Ken Taylor wrote:
Should I post patches to the discussion list or send them directly to you?
-Ken
Peter Amstutz wrote:
Good idea. This is what distributed version control is good for. While
you're at it, you can fix that synqueue.cc bug you pointed out, because
I haven't gotten around to it ;-)
On Fri, Mar 16, 2007 at 08:38:58PM -0700, Ken Taylor wrote:
In libs/vos/metaobjects/a3dl/sector.cc:
void Sector::setCollisionDetection(bool enabled)
{
Property::setProperty(*this, a3dl:colision-detection, enabled);
}
bool Sector::getCollisionDetection()
{
bool b;
Property::getProperty(*this, a3dl:colision-detection, b);
return b;
}
collision is spelled wrong...
Maybe I should make a bzr revision bundle so i can get my name in the
log
;)
-Ken
___
vos-d mailing list
vos-d@interreality.org
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
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Message handler problem
That's something that was introduced by the new event tables implementation in 0.24. The solution is to make the registration function a templated class, and for the subclass to call the base class registration function with the subclass type to ensure that the method handlers are associated with the subclass as well as the base class. On Thu, Mar 15, 2007 at 02:40:06PM -0400, Reed Hedges wrote: Ran into a slightly confusing thing that VOS does: If a base class registers a message handler, but then a subclass of that base class is the metaobject that's actually instantiated, then no messages can be delivered to that handler-- it seems that the list of handlers is keyed on typeid names, and VobjectBase is only able to find the handlers associated with the typeid of the subclass, not the base class. Any ideas on how we can fix this in VOS? Reed ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Message handler problem
On Thu, Mar 15, 2007 at 04:11:41PM -0400, Reed Hedges wrote: Peter Amstutz wrote: That's something that was introduced by the new event tables implementation in 0.24. The solution is to make the registration function a templated class, and for the subclass to call the base class registration function with the subclass type to ensure that the method handlers are associated with the subclass as well as the base class. Well, is there a way to avoid the subclass having to do this? I'm trying to make it easy to make a subclass of a local MetaObjects. I haven't thought of a way yet but I didn't look too deeply into the way it stores the function pointers in VobjectBase yet... Possibly, if typeid(this) in the base class will produce the typeinfo for the subclass, or the typeinfo can be propagated up some other way. The way the mechanism works is by getting the typeid() of the target vobject, looking that up in a table mapping object types to method pointers, then casting to the concrete type and calling the method in question. It's the lookup step (where it maps from the concrete type to the handler) that it fails if the method has been registered by the base class but not the subclass. -- [ 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
Re: [vos-d] Message handler problem
Try
templateclass T register() {
VobjectBase::registerHandlerT(message, T::handler);
}
(note T::handler)
This should work, this is exactly how it works in s5.
On Thu, Mar 15, 2007 at 04:49:17PM -0400, Reed Hedges wrote:
For one thing, apparently you can't do this:
class Base {
public:
virtual void pure() = 0;
templateclass T register() {
VobjectBase::registerHandlerT(message, handler);
}
void handler(Message *m) {
...
}
};
class VirtualDerived : public virtual Base {
public:
VirtualDerived() {
Base::registerVirtualDerived();
}
virtual void pure() { ... };
};
___
vos-d mailing list
vos-d@interreality.org
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
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] XOD questions
No, and it shouldn't do that -- the goal is to have the XML DOM structure reflect the VOS structure in a meaningful way. If you spread essential information for a single vobject all over the document such that it requires that you must process the entire document before being able to do anything, you're not really working with XML, you're working with XML-flavored tag soup. Of course, the internal cross-references we do have (mostly confined to the link tag, I think, which *is* a special case) use VOS paths instead of XML identifiers and anchors, but that's another discussion... On Thu, Mar 15, 2007 at 04:46:04PM -0400, Reed Hedges wrote: Does XOD or should XOD have stuff like the following? vobject name=a ... /vobject ... vobject name=b parent=a ... /vobject ... addtypes ref=/a types=ex:foo,ex:bar / Reed ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] XOD questions
On Thu, Mar 15, 2007 at 06:15:39PM -0400, Reed Hedges wrote: The reason I ask is that I want to load some 3D objects from a COD file, but then insert some non-3d children into one of those objects, and extend its types. This is the kind of thing that VOS is all about :) Practically speaking, I want to be able to re-export the 3D COD from Blender and clobber it while keeping my non-3d extensions seperate. So, it sounds to me like you want to append file A and file B to produce file C, and that some of those pieces in file B are intended to modify pieces of file A. I see why you might want to do that. Obviously you can't just 'cat' two XML files together, although with a little regular expression text mangling you could knock off the end tag of A and the start tags of B to yield something that will produce a valid XML document when glued together -- but this seems like a hack. I think a more elegant solution would be a program that merges two XOD files together by matching up vobjects to produce the final product. It's a little more work, but the solution is a lot more general purpose -- in fact, using the s4 loader interface, you can write the merge code once and then be able to use it to annotate both XOD and COD as well as imported files like ASE, 3DS, etc. I don't see why the XOD format should prevent stuff like that-- which are important abilities we have in VOS. If we have link why not parent (or the parent attribute)? parent would just be the inverse of link. Well, I feel like it should be more purely declarative and reflected by the DOM structure, and not require that you have to in effect execute a stream of commands 1, 2, 3, 4, 5, 6 in a specific order scattered around the file to reconstruct the vobject structure. The Vobject structure is (mostly) a tree, not log-structured data. XML is too restrictive here. XOD is already very specific to VOS in its element names; if you want to reuse a XOD along with some other XML you're going to be applying a trasformation to it anyway, and I'm pretty sure XSLT and XPATH are powerful enough to gather objects declared in different places in the file that have parent child relationships. Well, the idea was more to support the ability to import other file formats (X3D comes to mind, although it's maybe not a good example since it's really an example of how not to design an XML schema) using a straightforward XSLT transform. Of course, we haven't yet tried writing any transforms so I don't know if it's actually feasable. -- [ 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
Re: [vos-d] Question about Messages
A normal message is between two concrete vobjects. An update message is sent from a concrete vobject to update its replicas. For example, a property sending out a change notification. It's not a normal message, because the actual C++ object the message is delivered to is not a concrete Vobject, it's a replica. Another way of putting it, say we have two object A and B, and with remote replica B'. Normal messaging looks like this: A - B' - (network) - B Now B wants to update its replica. If it's just a normal message, the routing would have to look like this: B - (network) - B' - (network) - B But obviously that makes no sense, so we mark it as an update message, so the routing looks like: B - (network) - B' - (callback) - A Which is what we intended. On Wed, Mar 14, 2007 at 08:28:03AM -0700, Ken Taylor wrote: I'm sure if I spend more time tracing the code i could figure this out myself, but I'm in a lazy mood... What's the difference in the way Messages and UpdateMessages are handled by the VOS library? Why can't everything be treated as a plain Message? -Ken ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Metaobject Doc
On Wed, Mar 14, 2007 at 08:01:47AM -0700, Ken Taylor wrote: Ah, I sort of remember a post about that... but I thought it was simply for cross-language code generation. But if it's meant to also include human-readable documentation, and information for vobject structure validation, then that would be very sweet :) Right, the original motivating factor was to have an interface language that will make it easy to define cross-network and cross-language calls. That goal has expanded to include most other vobject aspects including children, embedded properties, namespaces, inheritance, and of course human-readable documentation. I'm also working towards having the vobject type document defined in itself, allowing reflection of the whole system. I've been doing a lot of reading, and I believe it would be accurate to say that the s5 design is evolving into an Erlang-meets-Smalltalk pattern: massive microthreading, highly reflexive dynamic runtime, but implemented as language-neutral kernel rather than a comprehensive programming environment. -- [ 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
Re: [vos-d] WXGLCanvas keyboard input problem...
So Ken, did you get a chance to make this change, and if so did it fix Ter'Angreal for you? On Sun, Mar 11, 2007 at 04:40:03PM -0700, Ken Taylor wrote: Peter Amstutz wrote: On Sun, Mar 11, 2007 at 10:27:52PM +0100, res wrote: I would say neither is right. Mouse enter and gain focus are two distinct events, and a mouse enter generally does not cause a focus change. Example: focus has an edit field, you want to type something. For some reason, the mouse gets moved over the WXGL view... would you want the WXGL view to take the focus? Probably not. Well, Windows is click-to-focus, whereas X is typically focus-follow-mouse, so I would say that it is a matter of taste. But you're right, another approach to this would be to catch the first mouse click event and make sure it takes focus in that case. I'm beginning to think that maybe the best idea is just to let the application decide what to do about focus. Document somewhere that in order to ensure that wxglCanvas to get keyboard events, you have to make sure to set focus to it. Or have it be a parameter to the class constructor (grabFocusOnEntry or something). It's not immediately intuitive that waiving your mouse over the 3d image on your screen is going to steal the cursor away from some important text box you're typing in, especially to windows users :) However, in either case, having CS broadcast an event claiming to have focus when it doesn't is wrong ;-) Yes, this is true! -Ken ___ vos-d mailing list vos-d@interreality.org 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 vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] What are some ideas for cool demos?
On Fri, Mar 09, 2007 at 08:34:43PM -0700, S Mattison wrote: But seriously, Reactor Pattern is a term that denotes an object-oriented approach to dealing with system-events that happen at any rate, even if they arrive simultaneously, from multiple sources. I'm not too familiar with it, but window-managers and operating systems should pay close attention to things like this. I think VOS already uses the reactor pattern, more or less. It just seems like a way of binding particular events to callback methods on objects. As for a 2d toolkit, every good 3d windowmanager should have one. Hopefully, a hardware accellerated one, in fact, that supports the proper 3d deformations that need to take place before rendering any 2d widgets or graphics to the screen. I feel that 2d and 3d primitives should both be accounted for, before any work on a 3d user-interface occurs. Likewise, there should be support for camera-oriented objects (such as vehicles), as well as objects that are unique to one specific client (such as interface widgets for those vehicles, because you don't want anybody else steering your car if you're the driver). I agree. I actually want to look into the SVG rendering model as a basis for the 2D drawing kit, and permit rendering to texture as well to screen overlays. Something else I'm thinking about is VNC-style optimizations for streaming bitmaps, so you can paint a continously update desktop snapshot onto a texture and render/interact with that. You also bring up a good point that it is very desirable to be able to present different UIs to different users, even if they are in the same space -- which is one failing of the current A3DL model that I intend to correct in s5. This is harder than it sounds, since it means that we now need to be able to distinguish between shared and non-shared per-user aspects of the 3D presentation. -- [ 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
Re: [vos-d] blog mention of VOS
interested in this, and that we've managed to create a small but stable community. So in conclusion, your business plan should look something like this: Step 1) Create an open platform for the online metaverse Step 2) ??? Step 3) PROFIT! Actually, the real plan is get funding for s5 development (Step 1). The goal would be to the point where we have a minimal platform that is usable by moderately technical people (say the average Linux geek) to make their own interactive spaces without requiring a whole C++ build environment or the exchange of many long support emails. At that point, we will start to build a real, long-lasting end user community. That will get us to Step 2, which is to go for more significant investment funds and build a company that can capitalize on the platform more directly. Then we sell VOS services far and wide, show up on the covers of magazines, and hopefully make it to Step 3 :-) [ 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
