The API release is approaching

Published on 17 December 2007

Something people often ask is support for more services. And that's what we do: in 1.1 we will be adding support for Picasa, currently the service most people are asking for. But we can not implement support for every single service in the world! We have to focus on the core of the browser, horizontal features, performances and stability. We can not implement the "long tail" of web services, simply because there are thousands out there.

This is why Ishika and me (helped by Marcus, Chris and others) have been working on an API that is easy enough for third party developers to pick up and use. We are currently writing documentation to explain how it can be done.

The API was more or less present, but a lot of cleanup had to be done and new interfaces and methods had to be written. Specifically, what we had to do is:

  • Well, make sure it can be done. At Flock we have a tradition of writing services in a modular way, but sometimes we added hacks in the core to enable a specific feature for a service. Extension developers won't be able to do that, so all that hacks had to go away. In each area, we designed a way to support specific features from the service itself.
  • Remove cruft. Flock's features set has evolved a lot in 2 years, and stuff that should no longer be there was remaining. The best example is the "photo" module. Since we traditionally supported only Flickr and Photobucket, it was called the photobar and everything in the backend was photo-something. Now that we support YouTube and AOL's Truveo, we changed it to "media" in the UI, but we also had to change interfaces names to avoid confusion ("A YouTube photo?"). More important, in Flock 0.7 (Cardinal), the photo module had some kind of social aspects: there were people in the photobar in a way. In 1.0 this created a duplication with our People code, so for 1.1 we moved what was left of the people logic out of the media module.
  • High-level methods to manipulate data. All the data we store locally (a cache of the friends list, your online favorites...) are stored in RDF, backed by a mozstorage database (sqlite), and accessed by an object layer. We were accessing that data directly, but that's not the best way to deal with data! We wrote high-level methods to store and retrieve data such as getFriends to get the friends list or addFriend to insert a friend in the local store.

As I said we're in documentation writing mode, but if you're a Warrior Developer who only need the code to understand, here are some examples:

There is an other side of the API: one that let you access all supported services in a unified way, if you want to create your own people bar... But I keep details about that for the next time ;).

TAGS: flock