UPDATED: I’m happy to report that these are all addressed in ObjectiveFlickr 2.0. Be sure to take a look!
I haven’t really been taking care of ObjectiveFlickr.framework for a while. For the past few months many things have demanded my attention. In between I’ve attended sfMacIndie Soirée 2008 and been to this year’s WWDC too. How time flies! I want to apologize for my late response on everything regarding the framework.
Lately we’ve seen fresh influx of discussions on the mailing list. Reading them, I always have this feeling that “it’s time we’ve got to update the framework.” There are a few things that ObjectiveFlickr needs to do better. Some of them are the result of operating system and development environment changes. Here they are:
- Better and clear run loop support
- Proxy support in OFHTTPRequest
- Fixing the delegate implementation–delegate should never be retained
- Support for both 10.4 and 10.5 targets
- Properties
- Linkage against CommonCrypto instead of OpenSSL (libcrypto)
- In with NSXMLParser, out with NSXMLDocument
- Support for the-device-and-the-OS-that-shalt-not-be-named-until-July-11th
Many of the items actually have to do with OFHTTPRequest and OFPOSTRequest, two nifty (I think) wrappers of Cocoa’s NSURLConnection (for receiving data) and CFNetwork’s CFHTTP stack (for posting data with progress callbacks). I use them all the time in many of my Cocoa projects, but even they feel a bit rusty now.
The removal of OpenSSL and NSXMLDocument dependency has also clear reasons (or, reasons-that-shall-not-be-mentioned).
I’m thinking of a new HTTP request class that solely depends on CFHTTP stack and does not use NSURLConnection. Which means that part needs to be redesigned. The existing OFFlickr* class interfaces look fine, but they’re also a bit wordy compared to their Ruby counterparts, ObjectiveFlickr-Ruby.
Should I create a set of new interfaces that break with the past, or should I maintain the interfaces and swap the internals? This is the question that is troubling me now. I appreciate any feedback on those design decisions.
I think backward compatibility with previous interfaces is less important than making an iPhone compatible version available quickly. Whichever path would result in the quickest iPhone-compatible library would probably please the most developers. My two cents …
I’ve been using ObjectiveFlickr for about a year now and I’ve run into limitations. I used it in conjunction with NSOperation/Queue and I’ve had a problem where my app started using a *huge* number of mach ports. Seems to go back to obj-flickrs’ NSXMLDocument dependency. It’s been a while but I can’t say for sure. Anyway, I haven’t shipped an app with it yet, so I have no problem with the API changing.
Thanks for ObjectiveFlickr.
Michael
Great,
I’ve just released a plugin for iPhoto using ObjectiveFlickr for non-commercial use.
I hope to use your future API in the future.
Thanks
Jean-Pierre
http://www.devconseil.com
For me the most important feature is compatibility with the iPhone SDK. I’m already using ObjectiveFlickr using the iPhone Simulator, but as long as NSXMLDocument is referenced, my app cannot be deployed on a real iPhone.
Do you have a target date for a iPhone SDK compatible version of Flickr?
Keep up the good work!
Have you considered porting ObjectiveFlickr for the iPhone?
I’m currently using a version of ObjectiveFlickr that I ported (threw many days of hair pulling) to “the-device-and-the-OS-that-shalt-not-be-named-although-I-think-it-can-now-be-named”
It’s combines TouchXML, ObjectiveFlickr and a fair bit of code changes and constant changes.
I now have it working 100% and am currently working on an app now.
Please let me know if you’re interested in knowing more. I’ll be keeping a close eye on your progress in this area as it will definitely affect our project.
Hi iDVB,
I apologize for not being able to devote more time to this project. My original plan was to (1) drop in the already-finished LFHTTPRequest as the stand-in of OFHTTPRequest/OFPOSTRequest, which are showing their age and design constraints, (2) offer a libxml2-based replacement of NSXMLDocument that coverts Flickr response block directly to property lists (NSDictionary/NSArray/etc.). But apparently fixing the framework is harder, especially when I know there are projects depending on the trunk.
A better idea might be to offer a branch out of the trunk. Do you find it a sound idea?