-----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----- _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
