GNOME Bugzilla – Bug 658576
Need API to get a FolksIndividual from his ID
Last modified: 2012-04-16 15:50:09 UTC
I'd need an API returning me a prepared FolksIndividual for a given ID. This is needed to implement DnD between the empathy contact list and empathy-chat (bug #655101), empathy-chat just cares about this individual so it shouldn't have to fetch the world to get it. This may or may not be related to search-based retrieval (bug #646808).
(In reply to comment #0) > empathy-chat just cares about this individual so it shouldn't have to > fetch the world to get it. I think there's no way to get around fetching the world to retrieve the individual, since you need the world to be able to know which personas link together to form the individual. i.e. Individual IDs only make sense when used with an IndividualAggregator. You can implement this at the moment by creating an IndividualAggregator, reaching until its is-quiescent property becomes TRUE, and then searching through its set of individuals for the one you're interested in. > This may or may not be related to search-based retrieval (bug #646808). Raúl and I were wondering if it would be possible to get some API into folks which would do the dance above for you. However, as you say, this is quite related to search; so I think it might be better to wait until we've properly designed the search API and see how this fits in then. We don't want to add API for this now, and then find that it doesn't fit in with the search API in future. I would suggest this is punted from 0.6.4 then.
(In reply to comment #1) > (In reply to comment #0) > > empathy-chat just cares about this individual so it shouldn't have to > > fetch the world to get it. > > I think there's no way to get around fetching the world to retrieve the > individual, since you need the world to be able to know which personas link > together to form the individual. Right, but do we really need to fetch all the Telepathy contact properties (prepare all the TP_CONTACT_FEATURE_*), and so generate loads of D-Bus traffic, in such case?
(In reply to comment #2) > Right, but do we really need to fetch all the Telepathy contact properties > (prepare all the TP_CONTACT_FEATURE_*), and so generate loads of D-Bus > traffic, in such case? That's bug #648805. :-)
(mass bump to gnome-3.4 milestone in our new milestone scheme; search this string mass move bug mail)
Now that Empathy is relying more on gnome-contacts, this is getting a more important problem (see bug #669676 for instance). Having this fixed would help a lot.
(In reply to comment #5) > Now that Empathy is relying more on gnome-contacts, this is getting a more > important problem (see bug #669676 for instance). Having this fixed would help > a lot. Presumably there's some code in Empathy/gnome-contacts which needs moving into libfolks. What is it?
That's http://git.gnome.org/browse/empathy/tree/libempathy/empathy-utils.c#n1202 which looks for an existing Individual and create one if needed.
Created attachment 210780 [details] [review] Add an IndividualAggregator.look_up_individual() method https://www.gitorious.org/folks/folks/commits/658576-look-up-individual After some discussion with Guillaume on IRC, I think this should satisfy the use case. The basic idea is that: 1. empathy-chat receives only an individual ID when started. 2. It creates an IndividualAggregator set to load as few properties as possible, and lazy-load the rest. 3. empathy-chat wants to retrieve the Individual with the given ID from the aggregator, and ensure that *all* properties are loaded for that individual (only). At the moment, the new method basically just looks up the ID in the aggregator and returns what it finds. Once bug #648805 is fixed, it will grow support for loading all properties of that individual (which is why it's an async method). The method also prepare()s the aggregator, just so that its use in empathy-chat should be as simple as: aggregator = folks_individual_aggregator_new_with_lazy_loading(blah); folks_individual_aggregator_look_up_individual(aggregator, callback); rather than needing a second async call to prepare() the aggregator first.
(In reply to comment #8) > The method also prepare()s the aggregator, just so that its use in empathy-chat > should be as simple as: > > aggregator = folks_individual_aggregator_new_with_lazy_loading(blah); > folks_individual_aggregator_look_up_individual(aggregator, callback); > > rather than needing a second async call to prepare() the aggregator first. I'm not convinced this is a good idea. Does other methods on the aggregator also magically prepare it? In tp APIs we assume stuff to be prepared by user in general. otoh it's so easy to just do in in vala... For the rest, that patch is good with me.
(In reply to comment #9) > (In reply to comment #8) > > The method also prepare()s the aggregator, just so that its use in empathy-chat > > should be as simple as: > > > > aggregator = folks_individual_aggregator_new_with_lazy_loading(blah); > > folks_individual_aggregator_look_up_individual(aggregator, callback); > > > > rather than needing a second async call to prepare() the aggregator first. > > I'm not convinced this is a good idea. Does other methods on the aggregator > also magically prepare it? In tp APIs we assume stuff to be prepared by user in > general. otoh it's so easy to just do in in vala... I don’t see any harm. The method’s specifically designed for the use case of a minimal folks client, so calling prepare() automatically removes some code from the client. Calling prepare() twice isn’t a problem, so the client can easily call prepare() themselves beforehand. Guillaume, do you have any opinions?
My concern is that if you hide the preparing step in some APIs, developers may get used to it being done internally and then will forget in APIs that does not do it internally. But anyway, feel free to commit like that, some APIs in tp-glib does it as well, tbh. ;-)
Merged without changes. Thanks for the review! If developers forget to use prepare() before calling other APIs, folks won’t work — it should be fairly obvious to them. commit c46ccee525d63ad247e6ed552b946b39867c45a8 Author: Philip Withnall <philip@tecnocode.co.uk> Date: Wed Mar 28 14:46:34 2012 +0100 Bug 658576 — Need API to get a FolksIndividual from his ID Add an IndividualAggregator.look_up_individual() method which currently just looks up in the map from IDs to individuals. In future, however, this method will also ensure all properties of that individual have been loaded if the aggregator has otherwise not lazy-loaded properties. (See: bgo#648805.) Closes: https://bugzilla.gnome.org/show_bug.cgi?id=658576 NEWS | 9 +++++++++ folks/individual-aggregator.vala | 29 +++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+), 0 deletions(-)