-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm looking at gnunet-fs-gtk core at the moment, and i don't get it.
It is my understanding that 'next_id' is simply an identifier, and its presence in metadata indicates that GNUnet client should do a search for that identifier, and any results should be considered 'updated' versions of the original. Fairly straightforward. add_updateable_to_ts() inserts "last_id" value it gets from the iterator as PSEUDONYM_MC_LAST_ID, while setting PSEUDONYM_MC_NEXT_ID to an empty string. GNUNET_GTK_master_publish_dialog_execute_button_clicked_cb() gets PSEUDONYM_MC_LAST_ID and PSEUDONYM_MC_NEXT_ID and uses them as "identifier" and "update identifier" respectively. When populating the treeview, PSEUDONYM_MC_CURRENT_ID_EDITABLE is set to FALSE for all updateable items, it seems, and TRUE for all "empty" rows (for new publications that do not update anything). PSEUDONYM_MC_NEXT_ID_EDITABLE is always TRUE, no matter what. But. GNUNET_FS_namespace_list_updateable () passes nsn->id as a second callback argument (which becomes "last_id"), and nsn->update as a last callback argument (which becomes "next_id"). So. fs-gtk pseudonym threeview seems to have four different item types: 1) "Blanks" - items for new publications, where you can edit both 'id' and 'next_id' 2) "Leaves" - items for updates, where 'id' is frozen with the value of 'next_id' from a previous publication, and 'next_id' is editable. 3) "Stems" - items that were inserted during the updateable items graph walking. Their 'id' is frozen with the value of 'next_id' from a previous publication, and 'next_id' is editable. They differ from the leaves in that there already were updates to these items. Updating them again will sprout more leaves (creating ambiguity, as one stem will now have >1 possible updates instead of 0 or 1 updates). 4) "Root" - initial publication that started the update graph. Its 'id' is frozen with the value of 'id' (!) from the initial publication, and 'next_id' is editable. Making "updates" with this item will, in fact, produce a new publication with the same identifier (thus increasing ambiguity, as one identifier will now yield multiple items), and not update anything. IMO (4) should not be in the list at all, why does add_updateable_to_ts() add it? And the need of (3) is debatable as well, since they break linearity of the update graph. If (3) is to be offered, it should at least be indicated appropriately (to think of it, (4) may remain in the tree as well, it just has to be unusable for publications). Do we _strive_ for linear update graphs at all? It'd prefer to encourage users to maintain linear update graphs. If someone wants branching graphs, we should offer a special widget for that (you ever seen git commit trees in tutotirals? that's how that special widget should look like, roughly). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLKp+AAoJEOs4Jb6SI2CwtWgIANHV0qyepzKytSnpBycP9hbN gohrabUHSfsq9KH6KOkWuXk8tU/8V2zAVYZ26LdxcAHbck50fmXmTyZSAbtpKNIY xgjVnSOWOrcLAgC+eKygnRxsu0Q+KVsk6Q2mX3t/JNOi6AUYkVICZhO9Izf9KSU1 j3i0oVdsmG9qnoo74Vx9+FRkvSOf74uLB5Q+U8O9TOZOMSvRkO9EV87XLlFNAvut tZg/IUkNAQi8HDqvlsrIMqcNGRRdqPIHOgTJsBXJ8Ww22xssSw+nrofHOTsOx0SJ KPJ5g54uwAK5XfqF+gCOVMCG6RtSPGyt9VH3ljgSahzb66M8Aayh1pkJML1jU/8= =uKtX -----END PGP SIGNATURE----- _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
