On Wed, Oct 17, 2007 at 02:53:49AM +0000, Lalo Martins wrote: > Also spracht Reed Hedges (Tue, 16 Oct 2007 10:24:27 -0400): > >> - type list > >> - child list > >> - payload, if any (eg properties) > >> - security capabilities > > > > - parent list? > > That would be problematic. Since the PCRs are already represented on the > "parent" side, having them repeated on the child would open a potential > spot for corruption. Also, it kind of breaks the idea that an object > only "commits" itself; if it adds a new child, then the child would have > to update its parent list. Most of all, I don't think it's necessary.
Yes, it's redundant and could be problematic. But what if you have some objects in storage, and you want to revive them, and have them insert themselves as children of another object? They need to remember what their parents were. I.e. any situation in which some version gets "disconnected" from its parents needs to remember what its parents were. This could just be a special case, where you keep track of them but normally you don't need to use them about them, except in situations where you're recovering from a network problem or change which broke the link, or moving objects out of persistant storage,etc. > >> Version control: how it's stored > > > > Hmm, it seems the only thing that you need to "reason" about merging is > > textual property data. > > I don't think so. I think the most common type of "merging" we'll have > is on child lists. True, their ordering could "conflict". Maybe in that case you just do the best you can, that's pretty easy for a user to fix in applications where order matters. (Or e.g. some code triggered by a listener has to resort them or whatever.) In text, if things get too messed up, it can be a real pain to fix manually, since information tends to span multiple lines. > > > I think we should really never have any > > situation in which there's a "conflict", unless you as a user > > specifically command it to merge two divergent branches, then of course > > you are there to resolve conflicts. > > Right. In all other cases, I suppose the newer revision overrides the > older one, when there is conflict. > > > What would the downsides be to treating payload (e.g. property data) as > > atomic? We can do diffs in a "version history" UI to present it in a > > nicer way. > > We could. > > >> Horizons > >> ======== > >> > >> Off the top of my head, I think we'd like to be able to set a horizon > >> per host, per type, and per vobject, in that order of precedence > >> (vobject overrides type). What if a vobject has two different types > >> that specify a horizon? Respect the first? The last? > > > > What is a horizon?? > > A preference of how many historical revisions to keep. You may set your > host globally to a horizon of, say, 10, to save space; or set some less > important object to a small number, because you don't care... Part of this might be archiving old revisions to disk, either in a known place where they can be called up again, or archive and forget. Reed -- http://interreality.org/~reed _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
