[GNUnet-developers] NS updates

[LRN]

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