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.
>> 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.
> 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.
>> Revisions and transactions
>
> Sounds pretty good, not sure I understand all the issues with local
> objects doing commits. Any particular call chain would be building up a
> list of commits, that would be executed by the initial vobject that got
> the message before it returns from handling the message and sends any
> reply?
The commits are executed immediately.
> Regarding transactions, is this something that could be saved for later,
> after the basic revision control is implemented,or does it have to be
> integrated now?
No, I think we could leave them for later. Let's need them first :-)
>> 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...
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://lalo.hystericalraisins.net/
technical: http://www.hystericalraisins.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
