[vos-d] new vos concept: listen conditions

[Reed Hedges]

Peter Amstutz wrote:
> lightweight condition or query language that could be used for things 
> like what you describe as well as searching and selecting objects for 
> download.

So it would have the same syntax as site searches etc?  That would be 
cool as a library that could be reused.   (A while ago I was thining 
about trying to rip the 'bc' program apart into a library but it's just 
not set up in a way that works for that (e.g. it does variable 
substitutions while parsing).)



lauses, 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. 

Is this for both remote listeners and local (within a program). For 
local updates only it should maybe be possible to have Listener object 
that aren't also Vobjects.  Hey, someone might even want to use VOS 
locally with no remote access, but...

One thing I'm finding is that using listeners and the listener API is 
slightly cumbersome; there are lots of little things you often need to 
keep track of, especially if you want to use one listener object to 
listen to multiple other objects.  This is one reason why I'm making the 
"listener toolbox library".  But I wonder if there are some things we 
could in the Listener API to make many things easier and more direct.


> 
> 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.

Well, you should be able to listen to any object individually, or 
object-and-all-children, or 
object-and-all-children-that-match-a-search-query, right? So you can 
pick what level you need.


> 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.

OK, sounds useful. Should be optional though, right?

Reed


>