MC, P2P, distributed collections
ducasse at iam.unibe.ch
Wed Mar 16 17:18:52 UTC 2005
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.
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.
More information about the Squeak-dev