Re: [GNUnet-developers] Listing Egos

[Martin Schanzenbach]

On Sat, 2016-01-23 at 16:49 +0100, Christian Grothoff wrote:
> On 01/22/2016 02:11 PM, Martin Schanzenbach wrote:
> > Hi,
> > 
> > <rant>
> > I wondered that as well. Not only does every developer have to
> > "remember" what he is told on connect (i.e. create a data
> > structure),
> > he is also supposed to update that data structure when there are
> > updates.
> > This is not how, for example, namestore works. 
> 
> It is, if you use the monitor API (which you should).
> 
> > Is there any technical
> > reason for this decision?
> 
> Yes, outdated views suck. Why would you want to have an application
> that
> shows the user stale state? And as how you keep your model is clearly
> application-specific, and as applications clearly need to support
> updates to the model, there is little we can do to automate this
> here.
> 
> > It seems to require (1) a lot of boilerplate management code when I
> > want to use identities and (2) inevitably lead to a lot of
> > copy/paste
> > code and bugs.
> 
> I'm not sure what the boilerplate is, given that the way the state is
> managed is application-specific. gnunet-identity-gtk adds/removes the
> entries into a GtkListStore, I don't quite see how that could be done
> in
> a generic fashion.
> 
> > Now that I think of it I think my recent additions might
> > all use the service wrong, in that I do not sync my local identity
> > list
> > (That I don't really want to keep but I have to since there is no
> > list
> > API call and no, I do not want to create my own "list" call by
> > reconnecting as I would have to add a comment that says "Reconnect
> > so
> > we get a list of egos") with identity service callbacks.
> 
> Not sure, you don't have to "explicitly" sync, if you callback
> properly
> handles add/remove, then your list will always be in 'sync', without
> you
> doing anything special. So the API may have helped you produce a list
> that is always in sync, as opposed to you having to explicitly poll
> to
> keep it semi-sync'ed.
> 
> > I mean, all consumers of this service will basically have to
> > implement
> > similar data structures and react to the callbacks in the same way.
> 
> No, some will have a DLL, some a GtkListStore, others may have a hash
> map, we don't know.  GUI toolkits represent the model in all kinds of
> ways, so asking the dev to just implement add/remove/update is the
> simplest thing we can do.
> 
> > That sounds fishy. In fact, I noticed that since I have to manage
> > all
> > identities in my DS anyway I never really use ego_lookup. There
> > literally is no use case for this API call at all as you would get
> > your
> > lookup result in the connect callback. After that, I have all
> > identities in memory anyway...
> 
> Well, as we say GNUNET_IDENTITY_ego_lookup is a *convenience* API, so
> it
> is not needed and if you're using the more general
> GNUNET_IDENTITY_connect() you never need it. ego_lookup is only if
> you
> really just need one name resolved and then you're done, which is a
> semi-common task for command-line utilities.
> 
> > </rant>
> > 
> > And I agree with zPlus: I don't want to manage identities. I want
> > an
> > API that gives me an Ego by key or name or list all (just like
> > namestore). Maybe a callback for changes is necessary as well, just
> > like namestore, so I don't have to poll for updates. So unless
> > there is
> > a technical limitation maybe at least harmonize namestore and
> > identity
> > API?
> 
> The existing API does exactly this: you don't have to poll for
> updates.
> The only thing you don't get is a data structure, as IMO it is
> actually
> a bad design for such an API to return say a DLL or a hashmap, as the
> API cannot know what data structure is appropriate for the
> application.
> So yes, you do have to implement the container logic, but as I said:
> that differs a LOT already between existing clients of this API, so
> it
> does make sense for each client to implement it. And that IS also how
> namestore and other GNUnet APIs generally function: do not expose
> data
> structures, only expose functional APIs.
> 
I agree the API makes sense in what it does. It's just the way *how* it
does it that is strange and IMO not how namestore does it. Namestore
has an iterator and a "change" callback.
Identity, however, has *no* iterator and a "change" callback that gets
called once upon connect where it works like the iterator of namestore.

I was just wondering if there is a reasoning behind the way identity is
implemented vs namestore (API wise).

- Martin

> 
> Happy hacking!
> 
> Christian
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers