[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] NS updates
Re: [GNUnet-developers] NS updates
Sat, 02 Mar 2013 16:49:21 +0400
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0a1
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
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
> 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
> What happens if your data structures on disk contain such a cycle?
> (Never trust any external inputs, not even our local disk
> 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/
-----END PGP SIGNATURE-----