Hi all, I came across this via Folks Bug 655116 and Geary Bug 774603. Currently, Geary manually implements Gravatar lookups for email sender's avatars, but I think it would make much more sense to use Folks for that instead.

So I'd be interested in adding Gravatar support to Folks, which means I would also have to implement this. Do you have any suggestions about what the API should look like, aside from the "search-harder" flag mentioned in bug #646808?

(CC'ing Phillip since he was also working on the original search API)

This is a complex topic, so unless you’re going to use the Gravatar support in more places than just Geary, I’m not sure it’s worth the time investment.

That said, here are my thoughts about the API:
 1. Do we want to eventually support more avatar backends than just Gravatar? Probably.
 2. Do we want to support them all at the same time, or would the desktop be OK if every application used the same priority list of avatar backends. i.e. See if the contact has an explicit avatar set; otherwise try Gravatar; otherwise try libravatar; otherwise use robohash.
 3. If we introduced the concept of search backends, they would have to be queried in a second pass after aggregation of normal personas is complete, which would be pretty slow, and would introduce additional complexity to what is already a very complex bit of code (the aggregator). I don’t like that.
 4. Caching needs to feature heavily in any case.

I think we probably want #2. When this feature was first thought about, it looked a bit like more competitors to Gravatar might appear; but in the grand old year of 2016 this doesn’t seem to have happened. So I think we can fairly safely abandon the need to support multiple avatar backends with absolute flexibility, and instead hard-code a list of avatar sources to check. As long as this isn’t explicit in the API, then the list can be changed in future. The key point is that every application using libfolks would end up using the same list of avatar backends, in the same priority order.

So I suspect the new API should be:
```
public class Folks.Individual
{
  public async LoadableIcon? get_avatar_or_fallback ();
}
```

When called, this would query the avatar backends (Gravatar, libravatar, robohash, etc.) in order until it found an avatar, then cache and return it. If the individual had an avatar already (Individual.avatar), then that would always be returned first.

This API has to be added to Folks.Individual rather than Folks.AvatarDetails or Folks.Persona because only the individual has all the necessary information (such as e-mail addresses) to be able to query for Gravatars.

(Travis isn’t around at the moment; sorry for my slow reply.)

I should make it clear: I’d be happy to answer questions and review patches as fast as I can, if you want to work on this. :-)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/32.