Like 112 people pointed me to Pavatar… okay not really, but I got a Google alert about it. Since “Pavatar – like Gravatar, but better!” got 2 votes on Digg, I feel a need to defend Gravatar’s honor. (What little it has.)
- The homepage says “Many of you noticed that the Gravatar.com service is offline quite a lot.” Heeeelloo-ooo! That is so 2007. Gravatar is now super-reliable.
- The chance of your page slowing down is much higher. Imagine you have 20 comments with Pavatars on a page, instead of using one service that might be up or down, your page is now calling 20 different domains, each of which could have a problem and be down. The browser also has to resolve up to 20 different domains. (Unless you implement caching.)
- Pavatar uses your own bandwidth, Gravatar uses ours.
- It’s fixed width, 80×80, where Gravatar allows any size up to 80×80. (And way bigger in the future! Or smaller. Did you know you can request a 1×1 Gravatar? Beat that! Actually 3×3 is my favorite.)
- There are no ratings.
- On the client side you need to support 3 different methods of autodiscovery.
- Pavatar allows animated GIFs. The horror!
- If I want to move a Pavatar to a different URL on my server, I break any place that has cached the old path. It’s not clear if or how ofter clients are supposed to re-autodiscover Pavatars, or if they hold on to it forever.
- If you implement the caching part of the spec you’re storing other people’s arbitrary images on your server.
- There’s no WordPress plugin on the directory.
- Finally, if you’re going to go the distributed route, do it right! Everything you need is in hCard, no need to invent new rel values. (I say this as a rel value inventor.)
On the bright side, Pavatar has a real spec that looks like a real spec. We have md5(). Point: Pavatar.
P.S. There’s no reason Gravatar couldn’t auto-discover hCards, or Pavatars, on Flickr avatars, etc. That way you could have a single API to whatever type of avatar someone is using.