Re: [GNUnet-developers] NS updates

[LRN]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?".

> 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.

> 
> 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.

> 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.

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRMfVQAAoJEOs4Jb6SI2CwZRAH/3T7bVywi5G9L6OkyLI9MfUr
seBoqJ6vvz5H8Hvp2PzMw43Cn1TuCA+vFJhAIzoKatvHUNhApSOFbegEiZ0nSuwm
UytgCz7GM/mUirDXZHriiIHB73O1n4g44pis6c/C6VMkKsQyzL1R7x43LV7iLM6x
JngA/1vlTfoOP0xq1IV6ox9nc69MioIh6HON7+xlOH6yVtcEBzyErwP76PQ598XU
uL3AMSsWV+l8mhENV8Yj+FLxK4ItcOTqQ6ty7O5ITGmZfrbaZf8XPWjCkT2JZVBY
ZNfucWRSKar3l0Y/cmu2rshvbK+zc/WGfM5/5Ocmhghrdf9e7i8a8fiDPvu1HR8=
=sIfk
-----END PGP SIGNATURE-----