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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
