Re: [vos-d] Listener notifications in S5
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
Re: [vos-d] Listener notifications in S5
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
[vos-d] Listener notifications in S5
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
