[vos-d] parameterized views

Tue Dec 12 00:51:27 EST 2006

Hi Reed,

This is essentially the two approaches to how you might implement a 
"view" that I have been considering.  On the one hand, you have some 
kind of server-side trickery that basically serves up different data to 
different people, so everyone just sees what they want to see.  On the 
other, you create lots of new vobjects that act basically as proxies to 
the "real" vobject but apply some transformation or filtering policy.

I'm not really comfortable with using the access control system for 
this, though, since security policies (or capabilities!) define what you 
*can't* see, whereas a view filters out what you *don't want* to see.  
Access control is also a very blunt instrument, since you now don't know 
if an access control error is due to being genuinely locked out or just 
a transient application of "you can't see that from where you are" 
policy.

Having discrete vobjects represent proxies has the advantage of being 
able to give a link to another user and then in principal they would be 
able to see exactly what you see.  The disadvantage is I am now looking 
at something that is not the "real" vobject, and so something that 
references the 3D sector as a whole would (applied naively) reference 
your personal proxy object and not the actual 3D sector vobject that 
everyone shares.  (Except they don't, because they have their view 
proxies).  The semantics of writing back to the original vobject 
"through" a proxy object also get kind of ugly.

I think the problem we're really trying to solve, the "parameters" in a 
parameterized view, is having a context or environment that modifies the 
results of an action.  As an example, I ask for the child list, and 
supply a context of "I'm at location XYZ and have an area of interest of 
10 meters" then the sector can use that context to constrain what it 
returns back to me.

What's really important, I think, is that you be able to capture a 
context and send it to another user.  So now you and I can refer to the 
same set of vobjects (no proxies to mess up our references) and if we 
need to reconcile our views, we can share the context that was used to 
create that view.  Access control is still applied, but it's an 
orthogonal issue.

I think this solves Kao's issue of having as much as possible a unified 
space for semantic reasons.  Also, a view should be a pretty well 
defined parameter space, so it should be possible to scan or iterate 
through views.  Going back to the original motivation, "Time" would be a 
view parameter, so by iterating or scanning through time you can see all 
the frames or checkins over the timespan of your animation or version 
control data.

I'm not yet sure what the best implementation of this.  Also, the line 
between what is a contextual parameter and a plain method parameter is 
somewhat fuzzy, although it's fairly obvious when the context is being 
used to affect the output of an existing core function like 
getChildren().

Thoughts?

On Tue, Dec 05, 2006 at 07:34:20AM -0500, Reed Hedges wrote:
> 
> I thought about this a little a while ago.
> 
> 1. My thought for server side control of a "View" was to use something 
> sort of similar to access control, where you write a set of rules that a 
> vobject can use when it recieves a list-children request. A given rule 
> also needs to be re-evaluated as the world changes in some way, and 
> generate a child-inserted notification.  What kinds of changes matter 
> would vary by each rule, so a rule would also be a listener to the world 
> and the avatar or whatever else. libvos could provide a specialization 
> of the Listener API for this particular purpose, integrated with the 
> View rules API.
> 
> That way has the advantage of basically being hidden from the remote site.
> 
> 2. Another possability is to simply have a "View" vobject for each 
> client that the server adds/removes objects to and from.  The client has 
> to use that View instead of e.g. the sector in a 3D world.
> 
> This way has the advantage of basically requiring no changes to VOS, and 
> is very simple, but with the disadvantage of extra Vobject overhead and 
> it requires that all clients be aware of the "View" convention.
> 
> I think you had this same idea Pete, at least for A3DL (we talked about 
> it in Boston this summer)?
> 
> 
> 3. For client side AOI in a 3D world, my thought is that 3D objects have 
> bounding box or radius properties, and since properties are now 
> basically part of the VOS core, support some simple math expressions 
> compared to property values in search queries.  Or a client does two 
> searches, once to get a list of all objects, their positions and bounds 
> info (which is not a ton of data) then a second search to only get those 
> that fall in its AOI.   Maybe a sector should suggest.
> 
> Reed
> 
> _______________________________________________
> vos-d mailing list
> vos-d at interreality.org
> http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d

-- 
[   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/20061212/84c6e201/attachment.pgp 