Re: [GNUnet-developers] Listing Egos

[Christian Grothoff]

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.


Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature