It's hard to keep up with all the mail that's come out all of a sudden, but your email in particular I wanted to respond to since it addresses some concrete issues that I do want to deal with in s5.
On Fri, Dec 01, 2006 at 04:09:17PM +0100, Karsten Otto wrote: > - PCR Numbering > > The way PCR numbering works is pretty nasty in light of heavy > concurrent access. Since there is no notion of graph locking in VOS, > it is impossible to do atomic test-and-set operations. Say you list > the children and find that #5 is one you want to remove. Somebody > else removes #1 in the meantime, your #5 gets renumbered to #4. Then > your "remove #5" request arrives, and you remove the wrong PCR. The way this is handled in s5 (and I think in s4?) is that you provide the name, link and position that you want to remove, and the operation only goes through if all three match. This does mean that code which calls removeChild() needs to be able to handle the error condition and retry the operation. Something we did in s4 (at your suggestion, in fact) was have the option for "non-strict" removal, so that it only checked the name and vobject and ignored the position. It may be that is the best policy in all cases, since the case where there are identical multiple (name, vobject) tuples is rare and somewhat pathological. This is kind of like the "test-and-set" operation you suggest. > A solution would be to support a form of graph locking, but this > would slow down operations considerable and introduce even more > traffic. An alternative would be to allow "empty" slots and never We probably need some kind of locking and/or transactions eventually anyhow. That's another can of worms. > change a PCR number once it was set. After all, only the relative > order is important for texture layers etc, and most PCRs are of the > "role type" where ordering does not matter anyway. The main problem with this is that you are allowed to insert a child into an arbitrary point in the list, at which point all the numbering needs to shift up. Also, if there are holes in the child list, you either end up with lots of empty slots or you no longer can do O(1) lookup but have to do some kind of search instead. > - Property Retrieval > > My application is unaware of the meaning of the various vobject > types; it works only on the level of the VOS graph structure. > Retrieving a VOS world is thus just a "dumb" recursive process: > starting at the sector, retriev the children, and the childrens > childen, etc. property:Property vobjects now become a problem, since > the application does not know if the property value is "important" or > not, and consequently if it should retrieve it for local caching or > better leave it alone. Currently I always fetch the type and length > first, and ignore property values of certain "uniteresting" type > (textures mainly) and of excessive length. This works, but querying > the property meta data creates a lot of extra traffic. Since your goal is to parse the world into an abstract knowledge model that your agents can work with, don't you need to look at the property context at some point? It doesn't seem unreasonable to expect that an application would know what it is looking for. To be sure, s4 makes this difficult since metaobjects were underspecified, but s5 is going to have a much tighter definition of vobject type (including method interface and what children it's allowed to have) so you'll have a lot more to work with. > It would be helpful if such meta information would be sent together > with the type information in the initial transfer. IMHO properties > *are* special and warrant this kind of special treatment. On the > other hand, a generic mechanism may be useful: Meta types could > register "intrinsic" properties whose value must be always provided > together with the type. Should be used sparingly, of course... I'm not sure what kind of meta information you're referring to, here. Properties are being integrated into the core and it will be possible to specify which properties are guaranteed to be part of a vobject. This will be implemented using "embedded children" whereby the property is stored as part of the actual vobject class instead of as an independent vobject. Actually, the design of embedded children is a topic worthy of its own email. > - Compound Updates > > Keeping position and orientation in separate properties makes sense, > since some vobjects may not need orientation, keep it constant even > while moving, etc. However, especially for avatars, position and > orientation change usually happen simultaneously. The fact is lost to > every receiving client; to them it looks like your avatar makes a > step, then a turn, then a step, then a turn... Yes, I agree, that always annoyed me. It's a problem of granularity, since it's reasonable to what to access the properties separately *or* together. One possibility is with embedded children, you have a concrete set of values that always are part of a particular vobject type, so you could ask for updates to consist of the entire vobject. > This kind of update should really be sent in a single message, to > preserve its semantics, and to save transmission overhead. Of course, > a special "a3dl:movement" message could solve this particular > problem, but would sort of break the property update architecture. A > generic "compound update" facility would be nicer for cases where > multiple property changes must be transmitted in a single update > message. Maybe a revival of the message block...? Actually, within the new design, bundling arbitrary messages together isn't so hard. However, there's another question, which is to what extent the receiving side needs to know about bundled messages -- it may not make much difference to bundle the messages if they just get split up and queued separately when they're received anyways. [ 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
