A few weeks ago I battled to get Concerto’s RSS output in a format that was friendly to OS X (10.5)’s RSS screensaver. It turned out the file extension was important to Leopard, so I used mod_rewrite with an .htaccess file to serve images at URL’s like image_1.jpg?select=content&select_id=1. Clearly the file extension, in that case, is .jpg… everything else (being the select=content&select_id=1) is the querystring.
Snow Leopard was released this week and much to my dismay our RSS feeds were no longer working, the screensaver was reporting that no pictures were available in the feed.
I set off on my mission to make it work again, starting with a flickr feed. Essentially I pair the feed down to one element and start massaging the different attributes with Concerto content to see if it works. I ended up discovering that the URL for an image now needs to end in a file extension, so something like http://farm3.static.flickr.com/2498/3869968920_9a53de458a_m.jpg?bananas=4 wouldn’t work (despite being a valid image) while something like this http://farm3.static.flickr.com/2498/3869968920_9a53de458a_m.jpg?bananas=.jpg would.
Since this change is slightly more confusing than a simple bugfix (we have to detect if the image Concerto is about to serve is a jpeg, png, gif?, etc) I committed a new revision to the API. The important changes to the previous version (008) start with a comment referencing 10.6 (so using find > 10.6 would bring you right to it).
If I had more time on my hands I would work on an OS X screensaver that didn’t rely on such strange image detection methods. There are certainly attributes available exposing the mime type if certain file types can’t be shown. I might be able to understand using the file extension to do some detection, but the last few characters of the query string… I think that’s a little outlandish.