> This is a really rather tricky to do properly. I think where you always > end up with this kind of thing is needing versioning not only for objects, > but also for "open containment" groups of related objects e.g. collections. > > If this is the kind of thing you want to do, it may be worth looking at > WebDAV, and the development work going on in the IETG Delta-V Working > Group. See http://www.webdav.org/deltav/ > > It might give you some ideas, at the very least. > > In regards of performance, I'd say the motto "first make it work, then make > it fast" might apply. Versioning over objects and advanced collections is > ******** hard! > > S.
As I read the webdav stuff, I'm reminded of the transaction control book I read (several thousand pages on transactions, commit/rollback, atomicity and finite state machines). Of course you're right. To do this correctly for all use-cases is a very hard task. Perhaps our use-cases need stating explicitly so that we at least know wether people need/require full versioning and transactional control or just want to do single-history commit/lock/up-to-date checks. This was why I like the idea of stating all of this in meta-data rather than code or schema. It's possible (and perhaps desirable) to put all the versioning logic/data seperate to the data model. And then of course everyone seems to use meta-data to mean something different... M _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
