Lalo Martins wrote: > On Wed, 09 May 2007 09:07:57 +0200, Karsten Otto wrote: > > I don't quite understand what you need versioning for. The bulk of > > changes you get in a shared word is avatar movement, which may wind up > > to ~30 changes per second per avatar. Do you really want to keep a > > record of all this? My understanding was that if you want to make a > > movie, its your responsibility to do the recording (and filling your > > hard disk), not that of the world/server. > > IMO, much of the "interesting" content may not actually be 3d objects, > but rather, information (text, models, images, sound, the works) which > you use the 3d objects to navigate trough and interact with. > > Anyway, in my mental model, the answer to that is horizons. For a > document (akin to a wikipage), you may define an infinite horizon: all > revisions will be kept. For most 3d content, the default horizon, which > is to be defined -- a month, a week, 200 revisions? And for things like > position of avatars, zero: no revision control at all. > > Alternatively, only record a revision when the object remains unchanged > for some period of time... but this is hairy to implement and I'm not > sure it would be worth it. >
You could approximate this by taking revision snapshots at specified intervals in time, as long as the object has changed at least once in that interval (or at least n times, maybe). That way you may not get every revision, but you could at least have one every hour or every day. You'd want this for complex objects that change often, but for which not every change is necessarily critical to remember. Another use for that might be recording animations -- store object movement 10 times a second or something. Though "animation" has a slightly different meaning than "revision history" -- you can have several different "animations" stored for the same group of objects, and only care about the relative ordering and timing within each animation, whereas revision history generally has only one thread with absolute ordering and timing. So animation could be generalization of revision history -- an animation is a series of object states ordered and timestamped (with a relative or absolute time) -- whereas a revision history is one particular series of object states with absolute timestamps. An object can have several animations associated with it, but only *one* revision history. The revision history can even store version changes for other animations in the object, but you wouldn't want it to store version changes for itself :) Addressing a previous version could be something like vip:://hostsite/my/revisioned/vobject/version/5 -- where "version" is a reserved contextual name that specifies an object's revision history (so maybe call it "core:version"? or "history:version"?) Animations would be similar: vip:://hostsite/my/animated/vobject/happyfunanimation/6 -- but have any name you want. Then of course you could have vip:://hostsite/my/animated/vobject/version/2/happyfunanimation/8 if the animated object is also revisioned :) (Actually, getting to the object might be more like vip:://hostsite/my/revisioned/vobject/version/5/object -- this way you can store metadata at the revision node, such as vip:://hostsite/my/revisioned/vobject/version/5/timestamp. And you can store data at the animation node, too, such as vip:://hostsite/my/animated/vobject/happyfunanimation/loopmode) Like I said in another email, when you store a revision of an object, you change its links to point to the correct revisions of all its child objects, too, therefore maintaining the integrity of the tree. As long as its child objects are versioned, that is. Just one possible implementation, of course! -Ken _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d