Re: [GNUnet-developers] NS updates

[Christian Grothoff]

On 03/02/2013 05:50 AM, LRN wrote:
> On 02.03.2013 07:34, Christian Grothoff wrote:
> 
>> So for me the question is more if we simplify to linear, to trees,
>> keep the current pseudo-tree (tree representing a directed graph)
>> and/or how we make whatever we choose to do _easy_ to understand.
>> I'm very open to suggestions (or patches ;-)).
> This is what i have in my local repository (attached).
> I'm currently putting some finishing touches on that, and then it'll
> be ready to be dcommitted.
> 
> This implementation can't handle branching at all. See that test_6-1,
> and its possible update test_6-2? If i publish _another_ test_6-1,
> with a different update id, this code will replace existing test_6-1
> with the new version, with its new update id. Previous test_6-1 and
> its possible update test_6-2 will not be shown.
> I think it's because of the multihashmap being used (that was your
> idea, by the way). 

I don't specifically recall that suggestion, but obviously it is
possible to do it either way.  Not sure which way is better.

> If i remove the multihashmap check, then it looks
> like this (attached).

What does your GUI do if I publish a new entry as 'test_6-2' and specify
the update identifier to be test_7 (thus linking two existing trees)? Do
you allow it? If so, do you add the existing test_7 tree under the
test_6-2 tree?  What if I add an update identifier that points into the
middle of an existing tree?  What do you do if I specify an update
identifier within the existing tree (i.e. publish an entry 'test_6-2' to
be updated by 'test_6')? Do you allow that?

Do you actually try to guard against the things that are not allowed? If
yes, what's the error look like? If no, how does your GUI handle the
cycle in the update graph? What happens if your data structures on disk
contain such a cycle? (Never trust any external inputs, not even our
local disk database...).

Just wondering ;)

Happy hacking!

-Christian