On Mon, 17 Apr 2006 14:40:12 -0400, Peter Amstutz wrote: >> http://dbstep.sourceforge.net/ > If it's not being maintained, perhaps we could fork our own version and > import it into the VOS codebase. That would save some work.
Yeah, I suppose that's the best course of action. > The current VOS SQL persistance uses bog-standard SELECT, INSERT and > UPDATE statements. Anything SQL, son-of-SQL, grandfather-of-SQL, > brushed-shoulders-with-SQL-on-the-subway, etc should support it. DBStep is just plain old SQL. What changes is the access API -- it provides a single, very simple and reasonable API, that works for all database back-ends. > b) There is no discrimination between properties, so data like position > properties which might be updated ten times a second will be pushed to the > database every time it is changed. It may be desirable to have some way > of throttling that to avoid too much database traffic. Good point. > c) I'm interested in ways of recording change history so that previous > states can be recovered. There is an experimental revision control > plugin which has in fact been running as the backend for the hypervos > section of interreality.org for a couple of years, but it is slow (it > uses RCS as a backend for property data, and a history log file for > vobject structure data) and the required tools to fetch manipulate the > repository were never really developed. Something to think about would > be a versioned SQL backend, which added a "version" column and only did > inserts, keeping around old rows... Yeah, I'm very interested on this... the requirement has come up frequently on the design of my current project. You also mentioned in the past storing wiki-like content, and history is essential for that. A few versions down the road, I'd like the revision control subsystem to be very complete, with most of the features you'd expect from bzr or svn (from svn the ability for one vobject to "descend" from another, so you can merge between them). Tracking vobjects -- as opposed to properties only -- adds a few extra requirements. - We'll be storing some marshaled representation of the child list; probably leave the representation up to the persistence system? Or is a standard representation necessary for merging across sites? - Objects now have an "unique" id at this point in time -- the name they have at the site root. For this system they need to *also* have an unique-over-all-time id, which we can probably generate by prepending a (creation) timestamp to the site id. - So the way I see it, one revision of a vobject's child list is a list of triplets: contextual name, persistent unique id, revision id. - A revision of one object is... what? Off the top of my head, the typeset, ACLs, child list, and if it's a property, prop type and data. Do we track all of these separately (could cause less headache for merges), or marshal everything to one large string? Or perhaps one string per metaobject (so two in this case)? Then there is the question of whether to store snapshots or some form of delta-ish representation. In the last year we have been through exactly this question with bzr and opted for weaves (or knits), so I suppose the same reasoning probably applies; but not necessarily, since I believe the data we'll be keeping will be typically more fine-grained (many small objects rather than a few large ones). Just throwing ideas around for reflection... it's probably too early to marry any decision, since I don't see us spending too much time on this at least for the next 2 releases :-) best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. -- personal: http://www.laranja.org/ technical: http://lalo.revisioncontrol.net/ GNU: never give up freedom http://www.gnu.org/ _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d