So let’s say I recently started using Flickr…. here. And let’s say that one of the things I found really annoying was they only let you add photos to a group pool… here… one at a time. And let’s also say, for the sake of argument, that I’ve recently got quite a bit of free time on my hands (NOT here for much longer), and a mad desire to develop for the Mac. Given those inputs, and given that Flickr exposes a pretty complete set of web services… here… I figured it was time to start playing around with those services on Mac OS X.

Note: When I mention that some things are “asynchronous” below, that’s only somewhat correct. None of the items below are multi-threaded, so things aren’t truly happening concurrently. However, they are scheduled on the run loop. So once they get scheduled, other things in your program can start happening - which keeps the UI somewhat responsive. But if something blocks waiting for network access - as sometimes happens when the NSXML classes load the requested URL, your app may stall. I think the only way around that is to start another thread and have it call back to your main thread when it’s done. Please correct me if I’m wrong.

Flickr’s Services

Flickr provides three different ways to talk to their services: REST, XML-RPC, and SOAP. REST is the simplest of the three - you put all your arguments in a URL, do a HTTP GET, Flickr attempts to service your request, and sends you back a bunch of XML. XML-RPC and SOAP both require you to package up your request in the appropriate, XML-based, format before submitting it. I’ve only been playing with this for a few days, but SOAP is probably the most flexible - and the most complex - format. Clearly, the benefit of using REST is that you can take your URL, fire up your favorite browser, and see Flickr’s response by just doing a “View Source” on the output.

After reading some docs, searching Apple’s developer site, and scouring the web, here are the options I see:

1. WebKit: Build a URL (for REST), or an XML document (for XML-RPC or SOAP), and use a WebView to get the resulting document back.
2. WebServices.framework: Apple provides these CoreServices functions and they work with XML-RPC and SOAP, can be syncrhonous or asynchronous, and use CoreFoundation types.
3. NSXML: Apple calls this “Tree-Based XML Programming”. NSXML classes accept a URL or file and then return a complete XML document in memory.
4. : Apple calls this “Event-Driven XML Programming”. NSXMLParser accepts a URL or file, and then calls a delegate when certain events occur (document starts, tag starts, tag ends, etc.)
   
5. Roll My Own? There’s probably another option here that involves creating and doing everything from scratch, but given the plentiful options above, I didn’t see a need to do this.

WebKit

WebKit is the parsing and rendering engine behind Safari. Because it’s designed to render the variety of pages on the web, and because I don’t actually need to render the replies I get from Flickr, I don’t think this is an appropriate solution. Although WebViews are simple to create and manage, carrying around even one or two in memory would create a huge footprint - all for features I wouldn’t need or use. WebKit’s frameLoadDelegate provides asynchronous notification of Flickr’s responses, but NSXMLParser and WebServices.framework also provide asynchronous execution. Pros: Provides easy use of the REST protocol. Cons: Too heavyweight for simple requests and XML responses; NSXML and NSXMLParser provide much easier ways to use REST without the resource footprint.

WebServices.framework

WebServices.framework provides a set of C functions and types to handle XML-RPC and SOAP web services. The framework is very robust and provides synchronous and asynchronous (via a callback) execution. Apple provides fairly complete documentation and sample code for the WSMethodInvocation types and how to go about setting parameters, submitting requests, and exploring the request and response XML. However, even with those benefits, I really want to get something up quickly; Exploring and debugging the request and response XML requires code, unlike using REST. Also, WebServices.framework does not provide a Cocoa interface and it may take some time getting used to the C-based WS methods and types. Pros: The easiest way to use XML-RPC and SOAP; Synchronous or Asynchronous; Lightweight. Cons: Debugging request and response XML requires extra coding; Uses CoreFoundation instead of Cocoa.

NSXML

NSXML is designed for reading, manipulating, and writing whole XML documents. Once you give it a URL, it synchronously loads the document and then allows you to explore the entire structure. Since loading from a URL or file are the only options, REST is the only protocol option. Similar to WebKit, though, is that NSXML stores the entire document in memory to provide for manipulation and exploration. But I’m usually just want a few tags; Having the whole document may consume more memory than I need. Also, I would have to add some extra code and manipulation to load the document asynchronously. If not, users could see a pause while the NSXML objects are loaded and built from a URL. Pros: Provides simple loading of REST URLs; Much lighter resource usage than WebKit. Cons: No simple asynchronous use; Some unnecessary resource footprint.

NSXMLParser

NSXMLParser is similar to NSXML in that you provide it a URL and it loads the XML document. However, instead of building the document in memory and letting you explore and manipulate, you give it a delegate and it calls the delegate. This means I can bypass parts of the document I’m not interested in and just pull the pieces I need. Pros: Simple loading of REST URLs; Asynchronous; Lightweight. Cons: No easy switch to XML-RPC or SOAP in the future.

I’m Going to Start With NSXMLParser

Based on the Pros and Cons above, I’ve started some code using NSXMLParser. Flickr doesn’t provide any capabilities or services that would require or benefit from XML-RPC or SOAP, and NSXMLParser seems like the most lightweight option. What about you? What are you using? I see that Frasier Speirs released the source code for FlickrExport, so I’m going to take a look at what he’s doing.