Heading towards a proposal for Zend_Service_Flickr

After Matthew said he'd be interested in a new "robust client" for ZF, I decided to sum things up. I have to sign a CLA, write a proposal and do some coding stuff if I want to contribute my code to ZF. But before going into the Zend Framework community, it's always a good idea to keep your head cool and think about some things first.

I need to think about the following topics:

1. Functional requirements
2. Structure of the service
3. What won't be supported initially

The functional requirements

I think it'll be a good idea to make a comparison to the existing Zend_Service_Flickr first. To list all the things about the existing implementation, it has support for:

1. Tags (limited to a search for photos)
2. Pools (fetching the group pool's photos)
3. The usual stuff for users and photos (read only)

It's quite clear the current Zend_Service_Flickr has tags and pools supports where mine implementation currently lacks these things. At the other hand, Sozfo_Service_Flickr has:

1. Support for users and photos (read only)
2. Support for sets (sets in collection, sets from user, photo in sets)
3. Support for collections (collections from user, collection from sets)
4. Support to authenticate your application (you start with a key, you end with a token)
5. An object relational type of handling the data

If you combine those two lists, I think Sozfo_Service_Flickr needs a couple more things until it might get approval. First, support for tags is pretty clear. Because tags are not really related to all other data types exept photos, its easy to implement.

The other thing is the pool support. If you want to use pools, groups and photos I think the minimum you need is searching groups, listing all photos from the group, fetching the context of a photo from a pool and list all members from a group.

So the have some use cases, I think it'd look like this:

//Photos is an array of Sozfo_Service_Flickr_Photo objects
$photos = $flickr->factory('tag')->search('delft');

//Groups is an array of Sozfo_Service_Flickr_Group objects
$groups = $flickr->factory('group')->search('your query');
$group = current($groups);
$users = $group->getUsers();
$photos = $group->getPhotos():

The OOP structure

Since I'm not a very experiented programmer, this isn't the most simple task. I have chosen a structure which might not be good at all, but please drop a comment if you have a suggestion.

The Sozfo_Service_Flickr class is at top level. It has a factory method to create objects (like photos, users, sets and so on) which I call "childs" (is there a better word for it?). Furthermore, it only does some storage for api keys, api secrets and authentication tokens.

The Sozfo_Service_Flickr_Abstract is the basic class for all childs. It does the request to the Flickr server, checks for errors and strips the result to be more usable. Furthermore it has the usual __construct(), __get(), __set() and setOptions() methods to provide a minimum of work to create a child object.
The abstract class can sign the calls automatically, when you have set the secret and token to the Sozfo_Service_Flickr instance.

The Sozfo_Service_Flickr_Photo for example has the getTitle() method and so on. More important: all childs have a _loadInfo() method which loads all information of the class. The method is called automatically if you try to fetch a property which isn't loaded yet.
E.g. you only need to do $photo->getTitle(). If the title isn't known at all, the photo object will call the _loadInfo() method after which the title is known and returned to you.

Not supported features

Because you can drown yourself if you want to do too much, it's a good idea to provide some 'IT WILL NOT' items to your requirement listing. Sozfo_Service_Flickr will at first place not:

1. Have write access, it's read only
2. No support for activities, blogs, favorites, interestingness, machinetags, pandas, geolocation, comments, notes and places

Will this be good enough? I hope so. Please leave a message if you have some suggestions!