[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] NS updates

From: Christian Grothoff
Subject: Re: [GNUnet-developers] NS updates
Date: Sat, 02 Mar 2013 04:34:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

On 02/26/2013 01:28 PM, LRN wrote:
> 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
> "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.

Right, so here you can put in an update (generation X+1) and specify the
identifier for generation X+2.

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

Not quite.  The issue is that there kind-of is no root.  Theoretically
the update graph can have cycles (update for A is B and update for B is
A).  So the code goes through some pain to try to find a "nice" way to
represent the (potentially) cyclic graph in a tree structure.  That of
course is a mess, but as we technically cannot prevent a cyclic
construction (as we may only have a partial view of the namespace), I
somehow had to deal with this issue.  So the 'root' is not the 'initial'
publication.  You could, in fact, post some item with identifier B to be
updated by C first, and then LATER post another item with identifier A
to be updated by B.  The tree structure is supposed to represent the
resulting directed graph as best as possible.

Additionally, even if the directed graph is acyclic, it can have
_multiple_ "roots" in the tree (update for A is C, update for B is C).

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

The goal was to coax users into making an update TREE (not linear), but
to make it "easy" to construct and keep a tree structure, while still
being able to somehow capture the mess you get if the user somehow
specified some arbitrary directed graph instead.  Linear was never the
intent here; however, as from our other discussions I might still be
happy if a future version of the GUI focused on simple linear update
graphs; the question then is how we deal with non-linear constructions
--- do we simply "forbid" managing those within the GUI? Is the entire
namespace ONE linear update list, or do we allow multiple lines? Or keep
trees and force a forest? Again, libgnunetfs allows much, and we might
want a more restricted version for the GUI.

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

Yes, having a special widget to represent the directed graph would also
work, but hacking that up is a major nightmare, and I don't see that
happen anytime soon.  Additionally, the question is if this wouldn't be
another one of those cases where we write a ton of code that then is
useful for 0.0001% of the users that understand AND need it. At this
point, I'd rather like to see a simplistic GUI for namespaces that may
not allow much but that users do understand and sometimes use, rather
than heavy work on custom widgets for complex operations few will ever
understand or need.

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

Happy hacking!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]