[vos-d] new vos concept: listen conditions

[Peter Amstutz]

(Forwarding this to vos-d for discussion)

On Tue, Jan 30, 2007 at 02:00:35PM -0500, Reed Hedges wrote:
> 
> This new thing would be like a different kind of listener. Or an 
> additional listener feature.  Many listeners are monitoring the state of 
> something waiting for it to be changed to a certain value or one of a 
> set of values or within a range of values, before actually doing 
> something in response.  This condition checking should be done on the 
> sending site, not the receiving side, so it doesn't have to send every 
> single change to the listener (potentially over the network).
> 
> It would be most immediately useful for properties.  Conditions depend 
> on the datatype.  For example, if an object wants to be notified of when 
> another object comes near it, instead of listening actively to all 
> objects, it sets conditions on those (remote maybe) objects to start and 
> stop listening.

Cool.  I was actually thinking of something similar, in the vein of a 
lightweight condition or query language that could be used for things 
like what you describe as well as searching and selecting objects for 
download.  The idea being for an SQL-like language that only consists of 
boolean clauses, mathematical operations and simple branches (no loops 
or recursion).  This would be easy to prove that it is "safe" since it 
would have bounded runtime and memory usage.  Indeed, this could also be 
an alternative to javascript on the client for UI tasks as it could be 
used to execute simple sequences of operations.

Such a language could be used to define parameterized views -- where 
what the client sees is explicitly filtered to reduce the information 
volume or to reflect a change over some dimension outside the vobject 
model (such as time).

> Does this make sense?
> 
> Also, can you give a brief overview of your ideas for implementing 
> listeners in s5 that you mentioned earlier?

Aside from conditions, a few other proposed changes would be:

a) The "listener" itself must be a vobject, so handling a change event 
is just handling a message.  Interestingly, I think this actually makes 
it easier when you have an application like Ter'Angreal (Interreality 
3D) with a mixture of both VOS and non-VOS objects, which may be subject 
to different concurrency and scheduling restrictions.  This means you 
can direct most of your listener events into one Vobject specifically 
dedicated to the task, rather than having a callback event fire with 
zero context and require the callback to acquire locks or go to 
second-stage scheduling to be able to work safely.

b) I want some way of setting up a listener in just one place, close to 
the root of the scene graph, instead of having to listen to each and 
every vobject in the space individually.  Not only is the current way a 
hassle, it's inefficient and has potential race conditions.  I'm 
thinking that at the world level you would set up some kind of blanket 
listener that expresses an interest in all position updates for the 
world (precisely the kind of case where you want a conditional filter!)

c) For large updates (say over 4-8k), instead of immediately sending out 
new property data, the vobject sends out an invalidation message (I've 
changed, you're out of date) and the remote side has the option of 
deciding whether to go out and fetch the updated value.  The reasoning 
being, beyond a certain point the extra round trip time to fetch the 
value is greatly outweighed by the cost of sending out data that may not 
be used at all.

-- 
[   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/20070130/3a55bcbe/attachment.pgp