Re: [GNUnet-developers] NS updates

[Christian Grothoff]

On 03/02/2013 01:49 PM, LRN wrote:
> On 02.03.2013 15:31, Christian Grothoff wrote:
>> 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
> My code is based on existed publishing dialog, which you wrote, AFAIK
> (i am not aware of anyone else doing GUI hacking).
>
>>> 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?
> The correct question is "Do YOU allow it?".

I did so far, but if you change code, things could be different ;-).

>> If so, do you add the existing test_7 tree under the test_6-2 
>> tree?
> That is exactly what happens.
> 
>> 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?
> The code that decides where "root" is was, again, written by you, it's
> in fs library. Everything depends on its decisions.

Ah, I though you were changing that code as well -- especially as you
talked about having made modifications to the FS API.

>> Do you actually try to guard against the things that are not 
>> allowed?
> No.
> 
>> If no, how does your GUI handle the cycle in the update graph?
> It doesn't. It shows what GNUNET_FS_namespace_list_updateable() tells
> it to.

Ok.

>> 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 ;)
> Apparently, GNUNET_FS_namespace_list_updateable() doesn't break the
> cycle. I've just published test_7-1 that specifies "test_6" as its
> update, looping back to its tree.
> And fs-gtk enters an endless loop, with recursion, and eventually runs
> out of stack.
> Note that this is for the case where hashmap check is disabled.

Oh, I thought you were rewriting that entire API as well. Hence my
questions.  Clearly we do need to enable that hash map check enabled then...

> A compromise solution would be to enable hashmap check, but make it
> more sophisticated - take more than just "id" into account.
> Also, when a previously-traversed item is encountered, don't just
> return immediately - add the item, and set it up so that choosing it
> will make the selection jump to its other copy somewhere else (which
> is the only copy that is selectable; through i'm not sure i can make
> GtkComboBox do that...), also marking it as such, and then return. So
> it will be a tree, but with loopends that user can traverse.

Sounds messy.  Might be easier to just forbid the creation of loops via
the GUI (and possibly the FS API as well), instead of having
non-standard behavior of a standard widget.

Happy hacking!

-Christian