Re: [vos-d] thoughts and plans
Am 27.06.2007 um 05:55 schrieb Peter Amstutz: I've been quiet, but that doesn't mean I haven't been thinking about VOS development. I'll try to describe some of the things I've been working on recently. Most importantly, starting July 9th, I will be devoting half of my time (2-3 full days each week) to VOS development. Coding, which has been stalled for awhile, will resume at that point. Great to hear, things have been too quiet lately. In the mean time, I have been fleshing out various s5 design details in my mind. The main subjects have been: - Scalability, clustering and recovery from failure. The general ideas is to use replication for load balancing and distributed locks for consistancy control. 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 :-) - Programming with continuations as a way of supporting concurrency without requiring threads. Also how to emulate continuations in languages that don't support them! - Authorization-based access control using object capabilities. I am still planning to write an email discussing capability security in VOS. I remember the discussion about these topics a while back. I'm looking forward to see what has become of them. Again, please tell us more! - User interface for the 3D client. This is a critical issue on which we have spent too little time in the past. Let me talk a little bit about the last part. This time around, I'm going to try and have a prototype 3D client in place even before we've finished writing the core. That way, we have (hopefully) something people can play with while development of the underlying network object model proceeds. I've spent a little while thinking about the interaction mode of the client, and came up with a few basic principals to follow: * It must be very open-ended. The goal is for the application to be able to configure itself to different task, be it a 3D game, social space or business purpose. * It should be usable by both novices who want a minimal browsing experience, and experts who are engaged in scene editing or development. * It should be designed to permit plugins or extensions to its functionality. 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... The model we have been using up until now has been the web browser, but it occurred to me that although familiar, this may not be the right model. Now, what is a highly popular application that is suitable for both viewing and editing, and is open ended... I think the right model is Emacs! Ok, I am not an Emacs user, so I may not understand your idea in its entirety. Still... I've put together a mockup screenshot here: http://interreality.org/~tetron/terangreal%20mockup.png Looks like Safari! :-) I thought you wanted something different than a web browser? In particular, what use are Tabs here? After all, interacting with a 3D world is about immersion, i.e. you interact with only one virtual reality. It is not at all like sorting thrrough files and shuffling multiple documents around on your desk, so it seems like the wrong metaphor here. Apart from that, it looks like you intend the interface to be purely 2D. Why restrict ourselves to that? Why not a separate 3D overlay, driven by a VOS graph in the same manner as the main 3D world? We discussed this stuff before, this seems to require just a few minor engine features like resetting the z buffer and so on. This solution would make for a much more flashy look in any case - who wants 2D icons if you can have true 3D icons, possibly with animations and all? At the top, like a web browser, you have the current URL (a vobject) which you are interacting with. Well, URLs were originally never intended to be visible in the original browser concepts. In fact, only very few of them are memorizable (http://interreality.org) and suitable for typing in as a starting point of a session. Most others include horribly long paths and cryptic parameters required by the webapp logic behind them. These are not helpful, you dont really want to see them at all. IMO the entire top half including bookmark buttons sould be the display part of a tool plugin, just like everything else, and should only show up if you select this particular tool. In the upper right corner, you have the major mode which defines how what type of interface to use to present the vobject. For a 3D scene, you might have a navigation major mode used for normal browsing and chatting, a construction major mode which provided controls for adding objects and moving
Re: [vos-d] thoughts and plans
On Wednesday 27 June 2007 11:29, Karsten Otto wrote: - User interface for the 3D client. This is a critical issue on which we have spent too little time in the past. Let me talk a little bit about the last part. This time around, I'm going to try and have a prototype 3D client in place even before we've finished writing the core. That way, we have (hopefully) something people can play with while development of the underlying network object model proceeds. I've spent a little while thinking about the interaction mode of the client, and came up with a few basic principals to follow: * It must be very open-ended. The goal is for the application to be able to configure itself to different task, be it a 3D game, social space or business purpose. * It should be usable by both novices who want a minimal browsing experience, and experts who are engaged in scene editing or development. * It should be designed to permit plugins or extensions to its functionality. 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... Why not use something like Sauerbraten to do the 3D engine work? I've put together a mockup screenshot here: http://interreality.org/~tetron/terangreal%20mockup.png Looks like Safari! :-) I thought you wanted something different than a web browser? In particular, what use are Tabs here? After all, interacting with a 3D world is about immersion, i.e. you interact with only one virtual reality. It is not at all like sorting thrrough files and shuffling multiple documents around on your desk, so it seems like the wrong metaphor here. I guess that it wouldn't be that hard to create a XUL client, and - if so - to create a mozilla extension (firefox plugin) so it starts accepting vos:// URI's, and, for those, open the view simmilar to that of the mockup... Apart from that, it looks like you intend the interface to be purely 2D. Why restrict ourselves to that? Why not a separate 3D overlay, driven by a VOS graph in the same manner as the main 3D world? If VOS is designed with that in mind, you'll be able to have as many kinds of clients as you want: a 3D client (using Sauerbraten as the engine, for instance), a 2D client (like a webbrowser-like client, or a firefox plugin, or something else...) or even a text client (MUD-like, as discussed a couple of months ago). -- Marcos Marado Sonaecom IT ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] vos-d Digest, Vol 52, Issue 4
I'm replying both to thoughts and plans and 3D engines posts. I have also been thinking about similar things, and I agree with the desire to combine Emacs+Mozilla ideas. I have also been thinking a great deal about tables, tags, trees, and types (talk about illiteration!). The reason I've been thinking so much about them is that every once in awhile, I'll come up with a new way of converting between one or the other. For example, unlike flickr.com tags, if there was a primary tag and a secondary list of tags (and you could tag tags with tags), then this kind of tag-based system would be isomorphic to a tree-based system (like directory structure) represented as a folder (representing the primary tag) containing the item, with symlinks to this item in other folders (representing the secondary tags). The only problem with this isomorphism is that tag-based systems usually have an implicit global namespace. Anyways, about the engines. The talk about the engines reminded me of a pattern I noticed in both my thoughts and in the Gtk+ system. There is an added bonus of extensibility when there are two layers of abstraction for plugins rather than just one. In the Gtk+ system there are GtkEngines and GtkThemes, and iirc, given a GtkEngine you may have any interface you want for a GtkTheme, which means given a GtkTheme, there may be only one GtkEngine with which it will work. So instead of designing a VosBrowserContentPlugin interface and a VosBrowserUiPlugin and a VosBrowserScriptPlugin interface, we should instead think of all the different kinds of plugins we would have, and design an interface for the engine that would handle this kind of plugin or this kind of plugin, and repeat. After this process, if we find parts of the engine interface in common between each kind of plugin loader, then we can design THE plugin interface which will not be a plugin loader, but a PluginLoader loader :) hehe. I'm still thinking whether or not this added level of abstraction is that great tho... Back to tables, tags, trees, and types. I honestly think that if the right metadata were available for a given dataset, you should be able to convert between these representations automatically, so much so that it should be a UI option when viewing a given dataset. I have already described an isomorphism between tags = trees (assuming a set of unique identifiers, and a primary tag), and I would like to remind of a common situation for converting between tables = trees, for example the doc hierarchy usually found in /usr/share/doc/project as compared to the documentation before installation, (perhaps found in /usr/src/project/doc). To illustrate this with some GNU utils: ID F1 F2 coreutils.pdf coreutils doc gawk.pdf gawk doc The only way to have these accessable either by project-first or doc-first methods are to mirror one directory structure to another: /usr/share/F2/F1 and /usr/src/F1/F2 are logically the same datasets represented in different orders. The best visual way to represent this kind of dataset is in a table, as shown above. This is not really an isomorphism since its really only one way, given any table, a tree-based structure can be constructed, but given any tree a completely different table-based structure might be used, and so is not unique (required for isomorphisms). On a different note, I was thinking about multiple inheritance, and and it struck me, this is no different than allowing tag-sets for super-classes, and going the other way, all tag-based systems can be represented by inheritance of tags rather than by folder-enclosure. So we also have an isomorphism between tags = types. Wow. Andrew Robbins ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] State of S4 Scripting (Lalo!)
What is the state of the S4 scripting branch (http://interreality.org/home/bzroot/s4-scripting)? Does the Python interface work? Thinking about what we should try to include in 0.24 (codename s4 swan song). Reed ___ 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
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
