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 ]

Attachment: signature.asc
Description: Digital signature

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

Reply via email to