[vos-d] VOS to RDF mapping

[Ken Taylor]

Peter Amstutz wrote:
>We probably need some kind of locking and/or transactions eventually
>anyhow.  That's another can of worms.

I think this is definitely needed and may even be worth getting a sketch of
it into s5 if possible. Even something simple, like being able to
temporarily lock an object for editing, would make programming in a
distributed writable space a bit less headache-worthy. If you wanted to be
especially ambitious, you could implement a round-robin system where
multiple programs are waiting for edit-lock, and are messaged when they
receive it (otherwise you'd have to poll for edit lock, which isn't very
efficient).

Atomic read-test-write type actions would be nifty, but probably not
necessary in the short term.

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

With all the recent talk about revision control on vobjects, I had a thought
about this: Internally, to save space, different versions of an object (or
different frames of an animation) would probably be stored differentially;
only the changes from the last version/frame are actually stored. These
"updates of the entire vobject" could consist of this kind of diff between
versions.

Another thought was -- why not just timestamp object updates? This way, two
updates may arrive separately but have the same timestamp, so the receiver
knows they go together. Also, timestamping network updates is usefull for
client-side prediction of physics and other such things, as far as I
understand. Finally, if the receiver wanted to record an animation, it would
have accurate time-stamping information.

Sorry there's been such a flood of emails today, btw :)

Ken