Re: [vos-d] Listener notifications in S5

2007-06-08 Thread Reed Hedges
On Thu, Jun 07, 2007 at 10:02:03PM -0400, Peter Amstutz wrote:
 On Thu, Jun 07, 2007 at 07:31:42PM -0400, Reed Hedges wrote:
  
  How do listener notifications fit in with the S5 
  vobject-as-logical-thread idea? I'm thinking specifically about impact 
  on ability to scale number of objects that one listener is listening to. 
 
 Well, my primary concern with the listener system is that if you are 
 interested in a large number of vobjects, the s4 model of adding a 
 listener to each vobject individually has a lot of overhead and 
 redundancy.  However, because we want to be able to support multiple 
 worlds hosted in the same process (or a world segmented over multiple 
 sectors) it's not desirable to broadcast every update to every 
 potentially interested party.
 
 The general strategy I have in mind is to have updates sent to some 
 intermediate vobject that represents a group of vobjects.  Then becoming 
 a listener to that intermediate vobject would be sufficient to be able 
 to listen to the entire group.

Seems that this kind of relay or chaining can easily be created just by
creating vobjects to do the relaying. Then you can structure it however you
want.  In doing some hypervos stuff I am creatingsome general purpose listener
tools. Most of them will also be MetaObjects so thy cane be created remotely.


  I wonder if we want to enrich the core listener types in S5 a bit, by 
  adding conditions that can be checked before sending a notification for 
  example.
 
 The main challenge with conditions is you either have to define a fixed 
 set of predefined conditions, or create a minilanguage in which you 
 write your arbitrary conditional expression.  Easier said than done, in 
 other words.


I think it would be a very useful feature. But we should postpone it until we
have more real world examples of what kinds of conditions would be required.
It's really just an optimization; but I've noticed two things: commonly the 
very first
thing that a listener does (or ought to do) is doa check on a new object's
cname or type, or on a property's data type; and that if you really want to have
dynamic response to vobject changes in an applications, you need to use a couple
layers of the current listeners (e.g. listen for children, then add a type
listener to new children with certain names, then add new listeners such as
property listeners in response to a type change), and it would be easier to make
very dynamic, event driven stuff if some of those more complex conditions were
available out of the box, and done efficiently.

But yeah, wait on this as a future refinement, need more data to determine how
to go about it.

Reed


___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


[vos-d] Listener notifications in S5

2007-06-07 Thread Reed Hedges

How do listener notifications fit in with the S5 
vobject-as-logical-thread idea? I'm thinking specifically about impact 
on ability to scale number of objects that one listener is listening to. 
   I'm guessing listener notifications are processed same as any other 
messages in the vobject's message queue/thread, right?   How would you 
set up parallel notification processing? Create a little listening 
vobject to recieve the notification on the main vobject's behalf, perhaps?

I wonder if we want to enrich the core listener types in S5 a bit, by 
adding conditions that can be checked before sending a notification for 
example.

Reed



___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d


Re: [vos-d] Listener notifications in S5

2007-06-07 Thread Peter Amstutz
On Thu, Jun 07, 2007 at 07:31:42PM -0400, Reed Hedges wrote:
 
 How do listener notifications fit in with the S5 
 vobject-as-logical-thread idea? I'm thinking specifically about impact 
 on ability to scale number of objects that one listener is listening to. 

Well, my primary concern with the listener system is that if you are 
interested in a large number of vobjects, the s4 model of adding a 
listener to each vobject individually has a lot of overhead and 
redundancy.  However, because we want to be able to support multiple 
worlds hosted in the same process (or a world segmented over multiple 
sectors) it's not desirable to broadcast every update to every 
potentially interested party.

The general strategy I have in mind is to have updates sent to some 
intermediate vobject that represents a group of vobjects.  Then becoming 
a listener to that intermediate vobject would be sufficient to be able 
to listen to the entire group.

I'm not sure about the best way to define this group.  One possibility 
is to define the group as a vobject's subtree of children.  In this 
scheme, update messages would be sent to the vobject's parents and 
passed up to the hierarchy to the relay vobject.

Another way would be to maintain something more similar to the current 
system, continuing to maintain listener lists on each vobject, and 
permit an interested party to listen directly as well as having the 
relay vobject also listen to each vobject.

Generally speaking, some kind of chain of lists of listeners -- going 
from the most specific to the most broad -- seems like the right way to 
go.

I'm guessing listener notifications are processed same as any other 
 messages in the vobject's message queue/thread, right?   How would you 
 set up parallel notification processing? Create a little listening 
 vobject to recieve the notification on the main vobject's behalf, perhaps?

Parallel notification processing is one of the things that got us into 
the awful mess that is the s4 Crystal Space plugin to begin with, so 
requiring notifications to be processed serially is not something I 
consider to be a problem.  The vobject can pipeline requests (start 
processing the next one while waiting on something for a previous one) 
or spin off additional vobjects to do parallel processing if such a 
approaches make sense.

 I wonder if we want to enrich the core listener types in S5 a bit, by 
 adding conditions that can be checked before sending a notification for 
 example.

The main challenge with conditions is you either have to define a fixed 
set of predefined conditions, or create a minilanguage in which you 
write your arbitrary conditional expression.  Easier said than done, in 
other words.

-- 
[   Peter Amstutz  ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[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 ]



signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d