One of my first tasks upon starting at Flock was to design/clean up the XPCOM interfaces we use to represent web service components (Flickr, Facebook, etc.), accounts on those services, and specific APIs implemented by those services. We made great strides in that regard at the end of 2006 and beginning of 2007. Then some cleanup happened over the last two months or so. We now have a pretty workable model as described here.

We’re continuing to refine it, however. What follows are some changes we plan to make on trunk, probably over the course of the next month or so.

Web Service Interfaces
The major changes here are the introduction of flockILoginWebService, a slight reorganization of the inheritance hierarchy, and the elimination of flockIManageableWebService.

  • flockIWebService – Any web service that Flock integrates with. Does not necessarily have to support accounts. All account-related functions would be moved to flockILoginWebService.
    • flockIMediaWebService – A web service that supports the concept of media streams and/or queries.
      • flockIMediaEmbedWebService – A media service for which we support embeddable media (ala the Flock Magic overlay).
    • flockIPeopleWebService – A service that has a concept of “people”, but not necessarily of friends or a social graph. This would replace the current flockIMediaWebService#supportsUsers flag.
    • flockILoginWebService *NEW* – Any service that supports the concept of user accounts. (This would include every service except for Truveo in the current roster.) All account-related methods from the current flockIWebService interface would move to here. This interface would also subsume everything currently in flockIManageableWebService.
      • flockIBlogWebService – A service that supports blogging.
        • flockICustomBlogWebService – Used to support self-hosted blogs.
      • flockIMailWebService – Webmail services.
      • flockIBookmarkWebService – Online bookmarking services.
      • flockISocialWebService – A service with a social graph, wherein users can have friends in the People sidebar, etc. These services will also implement flockIPeopleWebService. (If XPIDL let us do multiple-inheritance then this interface would inherit from flockIPeopleWebService as well. It doesn’t, sadly.)
      • flockIMediaUploadWebService – A service to which users can upload media using Flock’s Uploader. (This interface would also inherit from flockIMediaWebService if possible.)

Account Interfaces
These are basically just being renamed to make them more readable.

  • flockIWebServiceAccount – Can be associated with any flockILoginWebService.
    • flockIBlogAccount – renamed from flockIBlogWebServiceAccount.
    • flockIBookmarkAccount – renamed from flockIBookmarkWebServiceAccount.
    • flockIWebmailAccount – renamed from flockIMailWebServiceAccount.
    • flockIMediaAccount – renamed from flockIMediaWebServiceAccount.
      • flockIMediaUploadAccount – stays the same.
    • flockISocialAccount – renamed from flockISocialWebServiceAccount.

API Interfaces
Web service API implementations should be XPCOM components, but not XPCOM services. This is because we may want multiple instances of them. For instance, both Delicious and Magnolia use the Delicious API. Therefore we should have an instance of flockIDeliciousAPI for each service, so that the API states can be maintained separately.

  • flockIWebServiceAPI *NEW* – defines generic authenticate(), deauthenticate() and call() methods, and an isAuthenticated property.
    • flockIFacebookAPI
    • flockIMovableTypeAPI
    • flockIWordpressAPI
    • flockIDeliciousAPI
    • etc…

Blogged with Flock