[vos-d] new vos concept: listen conditions

[Reed Hedges]

Karsten Otto wrote:
> Funny... always before, VOS basically was a system for object state  
> replication. However, what you describe sounds more like a publish- 
> subscribe system! I wonder whether this paradigm shift is truly  
> intended? Or is the "subscription" just a way of optimizing network  
> traffic?

Yes, well the way that VOS's "state replication" works is by a simple 
publish-subscribe.   Though in reality, it's just a message and reply: 
start-listening and notify-child-inserted and notify-property-updated 
messages etc.

Yes, this idea is an optimization.

> 
> Also, I don't quite understand the way this is supposed to be  
> implementated. Does every vobject have to understand the subscription  
> language, restricting the updates it generates? Or do they behave as  
> before, but the site filters updates by subscription before sending  
> them over the network?

It would be an addition to the current simple listen request. You'd 
probably do something like add a field to the listen request message 
with the condition. I don't know whether it would be implemented in the 
Vobject or Site, Peter could comment on the best way to do that maybe.

Examples:

  * Listen for new children added to parent object P, but only send 
notifications if the contextual name is "foo". (So it only notifies this 
listener of "foo" named children).

  * Listen for new children added to parent object P, but only send 
notifications if the type of the new child has one of these types: 
"a3dl:object3d", "misc:avatar", "foo:bar".

  * Listen to a property, but only send notifications if it has datatype 
"integer".

  * Listen to a property, but only send notifications if it has datatype 
"vector: float" and "distance" in space between property value and some 
position X is <= 20.  (this could be expressed in a simple math 
language, or as a special "distance" function).

Or, of course, simply:

  * Listen to a property, with no condition (currently available)

The reason I thought of this was just sitting and trying to imagine an 
information system constructed only of very many vobjects and listeners; 
so that when you change one value, the effects "ripple" through the 
system as listeners fire.  It could be that the vast majority of those 
listener updates are in fact completely unneccesary, since the first 
thing the listener will do is do a check like those in the examples 
above.  In a distributed system, this results in a lot of useless 
packets and waiting around for the network to do its thing.  In a local 
system, it's just going to thrash and churn for no good reason.

Reed