A Provider is Added

So I finally did it - made a real contribution to Drupal. It isn't live yet, but I think it is RTBC (Ready To Be Committed). In this case it was a new provider for emfield image allowing users to embed smugmug images into their pages similarly to the existing providers such as Flickr, Photobucket, etc.

Some easy, Some hard...

So was it hard? Well, like all coding some was easy, but there are always gotchas.
The easy part was copying an existing provider file (I used the flickr.inc provider file as my starting point). I didn't have to worry too much about finding out which hooks I had to implement because they were already there. Didn't really even need to worry about where these hooks were coming from (was hook_x defined by emfield, cck, or something else?). All I needed to do was figure out what role each function seemed to be playing for the provider (parsing a URL, retrieving an embed link) and attempt to duplicate that. That worked out great. And as it happened I figured out where all the hooks were coming from as I coded it anyway :).

What about the hard? Well, for one thing smugmug's api - not surprisingly - had a variety of differences from flickr's api. In some cases these were improvements - for example smugmug returns a larger array of image size URL options.

Other things were much trickier. Smugmug keywords (tags) perhaps the worst. I may have to write a separate post about that. Suffice to say that v1 of the smugmug provider simply provides the raw smugmug keyword string with no attempt at parsing it for now. It will be on my to do list to fix that (preferably by adding my voice to others in the smugmug dev community on the need for their api to do this properly!).

The other big issue is that all smugmug api calls require you to first get a session key. Two issues here. The more trivial issue is that it means at least two calls to smugmug. More importantly though, this caused a potentially serious issue with caching of information. It is important for emfield modules to cache information they retrieve from the provider when possible to avoid overloading the provider when many drupal sites start hitting their api. Emfield uses an argument hash as the cache id. The problem? If we keep getting new session ids then every single cache item with the old session id is now invalid. Oh, and I forgot to mention, we can't just keep the smugmug sessionid in the cache indefinitely because it eventually times out (took awhile to figure out what the timeout is, it wasn't documented!). So this problem means many more calls to smugmug and unnecessary increase in the cache table size.

I had a number of ideas to fix this. Some involved significant change to the way the emfield_request_xml works (specifically allow specific arguments to be excluded from the arg hash). However, for now I wanted to find a solution that would work totally within my include file so I wouldn't have to introduce the delay of having many other providers to test to make sure I didn't break them. And anyway, that is really a separate issue yes? So I found my own local solution. Basically I did my own call to cache_get and if the smugmug session held in the cache is too old (>5 hours) then I just cache_clear_all to get rid of just the smugmug cache items. There are a couple of tweaks I can still do on it, but for now this is a fairly clean solution that won't overburden the smugmug provider while adhering to the proper use of the drupal cache table.

So it's out there - soon to be in the wild. I'm very excited.