On Thu, May 03, 2007 at 04:23:38PM +0200, Karsten Otto wrote: > Funny... the problems you mention actually result from a lack of > semantics! > ... > The only *real* solution, both in S4 and S5, would be what the games > do: Send a custom "movement" message... and loose the genericity of > the VOS platform.
This is actually really insightful. We talk a lot about how it's easy to extend the semantics of vobjects. Why not be able to extend the sematics of messages? Presently, types list their entire inheritance in the name. For example, "a3dl:object3D.sphere" is in the a3dl namespace, is an "object3D", with additional semantics indicating that it is a "sphere". If a program doesn't understand (or doesn't care about) the type "a3dl:object3D.sphere", it is permitted to interpret it as just "a3dl:object3D". Why not do the same for messages? For example, "core:property-replace" could have specializations "core:property-replace.movement" and "core:property-replace.teleport". Your implementation could handle them separately, and they would be permitted to have additional fields, but would indicate explicitly to the interface that the action (and fields) is an elaboration on "core:property-replace". Such messages could be "sliced" to their simpler versions if a handler for the specialization isn't available. > My hope is that this problem might get smoothed over a bit in S5. I > assume that both position and orientation will likely be embedded > children of an avatar vobject. If you change both, you need to > acquire the lock of the parent, change the values, and release the > lock (ok, VOS will do this for you transparently). In this case, VOS > should defer the update notifications until the parent lock gets > released, and the send them all in an atomic "compund > update" (message block?) which is semantically slightly closer to the > actual user action. I am not quite sure how you could squeeze a > "don't-interpolate" flag into the mix though - unless it is an actual > embedded child of the avatar vobject, which is somewhat messy. What you want is a transaction system for updates. This is something I've been mulling over for awhile, but haven't really found a good way to do it yet. The problem isn't so much for transactions themselves, but that we also was atomic *notify events* so that if I perform a transaction that changes three values, listeners are notified in such a way that they can know that the entire set of values changed at once, so they get a single atomic callback and not three callbacks for each of the three values that changed. That's what makes things like physics work, where position and velocity need to change atomically. Any thoughts on a good model for this? The s5 design is going to make this easier, I think, because instead of strict callbacks for notify events, it will use the same message passing system as for method calls. This might make it easier to implicitly or explicitly recognize cases where notify events should be combined. -- [ 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
