On Fri, Jun 29, 2007 at 09:22:41AM -0400, Reed Hedges wrote: > On Wed, Jun 27, 2007 at 12:29:43PM +0200, Karsten Otto wrote: > > 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 :-) > > My feeling is that this would be like an optional add-on to a vobject. > We would still have the single master local object with remote proxies > (that's still one logical option; it's the libvos API that calls the > remote objects as "objects" not "proxies" and gives them the same > interface). Replication means making copies of local objects and > moving them to different sites, but keeping them in sync behind the > scenes, so a change to one copy gets reflected in the other copy. > This requires the locking mechanism during that synchronization; > locking would be generally useful as well, even if you're just talking > to one object as a client, not a replicator > > IS this kind of thing what you are thinking of Pete?
Yes, you've got it. The replication ideas are something that would be mainly implemented on the back end to help a large site scale up, although it could also be used to implement purely peer-to-peer shared sites. There are really two types of replication, the first being between hosts which trust each other and are authorized to make any change, the second being between mutually suspicious hosts where access control checks must be enforced. The first case is where the "master" local object is itself distributed, and we use either coarse-grained locking (a host takes responsibility for it over a long period of time, minutes, hours or days while still allowing for another host to take over if the owner releases the lock) or distributed transactions to sequence changes. The second case is the remote object case, where we copy the object's state for the purposes of caching (and possibly replicated computation, i.e. scripts), but write requests are still sent upstream and sequenced the master object, and access control is enforced. Between a lock-based system and a transactional system, I'm leaning towards the latter -- in particular, using transactions as the basis for communication that change object state. A change request would bear fields saying it effects a change from state A (revision 1 with hash code XYZ) to state B (revision 2 with hash code ABC). All the interested parties would check the state of their local copy to ensure that the starting state is current, and then send their assent to dissent with the transaction. The sender would collect the responses, determine if everyone agreed and send a "commit" message, or abort the transaction, do any housekeeping required to update to the current version, and run it again. I believe this is more or less how David Reed's distributed transactions work, which are used in Croquet (I need to do some research to make sure). The main difference in how VOS and Croquet would handle this is that Croquet distributes the *inputs* to computation, and distribute the *results* of computation. > > > 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 > > Yes, I would skip the "back" and "forward" buttons, and the big bookmark > buttons. Well, the idea was that even in a 3D space, you still want some kind of history of where you've been. Same for bookmarks. > > 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. > > Well, we could do what some web browsers do, which is hide the tabs UI > if there's only one tab. You might want to be working in multiple > worlds. SOmetimes immersion can be a pain because it forces the world > metaphor on you. LEt's say your lurking in one world waitingc for > people to arrive, but also participating in the other. Or you are > moving objects back and forth between worlds. Maybe one of your tabs > is the local world within terangreal (i.e. the one that terangreal > starts up in that has some instructions in it) that you're using as a > scratch space to create objects, then moving them to the other when > done. Yes, I'm firmly committed to the idea that the application should be able to participate in many spaces at once, for the reasons outlined above. > > 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 > > I agree, having the ability for the client to display local 3D stuff > for UI purposes might be neat, but there's some stuff that just gets > hard in 3D. I think it's a good idea to start off with typical WIMP > graphics (using wxWidgets) so that we can make 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 [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
