[vos-d] thoughts and plans

[Peter Amstutz]

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  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[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 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20070629/7fed5b43/attachment.pgp