[vos-d] VOS to RDF mapping

[Karsten Otto]

Oops, sorry for the weird formatting. Apple Mail somehow messed up my  
copy/paste action there.

Reviewing this, I remember a few things that struck my attention  
while I was working with barebones VOS (e.g. without the official  
codebase). Maybe it is not too late to consider this for the s5 rewrite?

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

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


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

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


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

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

Also, this may require a change in the API, with a setTransform(pos,  
ori) or similar for simultaneous updates.


Regards,
Karsten Otto (kao)