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