Hi colin

marcus made this morning an interesting remark about MC. he said that 
what he would like is
something that does not only save a version on the server but merge it 
with the latest version, check conflicts and commit it. I do not know 
if this is making sense to you but I wnated to pass you the idea.

Stef


On 16 mars 05, at 17:52, Colin Putney wrote:

> Cees de Groot wrote:
>
> [snip lots of p2p issues]
>
>> The alternative is to have these assertions to carry along some  sort 
>> of MC-like ancestry: every version gets a new UUID, and versions  
>> state what their parent is. But that would mean that these assertions 
>>  would get large. As they are the glue in the whole distributed 
>> information  repository and therefore quite common with probably 
>> frequent updates this  could mean quite a bandwidth burden...
>
> Actually, this is one area where the versioning model of MC2 is a big 
> improvement over that of MC1. With MC2, versioning the presence 
> assertions might be feasible.
>
> With MC1 we'd essentially be slinging around a versioned list of all 
> the nodes in the network. Every node would be generating its own view 
> of the list, based on what it knows and constantly remerging based on 
> what it's getting from other nodes. Ugly, ugly, ugly.
>
> With MC2, each presence assertion would be versioned separately. Thus 
> you'd only get new versions when some node left or joined the network, 
> and you'd be able to compare it with your current notion of the status 
> of the node: either it's the same version (status hasn't changed), 
> it's an older version (you can discard it), or it's a newer version 
> (you need to update your status)
>
> The versioning overhead for this stuff would be pretty small - I'd 
> guestimate something like 32 bytes + 24 bytes per version of ancestry. 
> I'm liking more and more the idea of doing mc2 network repositories 
> via p2p.
>
> Colin
>
>