After some more thought (nothing like a bad day to get your brain working in the background...) I came to this conclusions about the classes and namespaces that make sense for the Perl Flickr API.
First I think there really is room for the two sets of modules/classes I discussed: a lower level one which simply models the published Flickr API directly on Perl structures of hashes and arrays, and a higher level one which models the "logical" level of users, photos, photosets, etc.
Then I seem to have reached a reasonable naming structure for them. My current plan goes along these lines:
The lower-level API-mapping classesThese should go into the Flickr::API namespace and should be named following the Flickr API's naming convention, namely there should be the following classes:
Each of these classes should then implement the functions that are published on the API, for instance Flickr::API::Photos::getInfo(), Flickr::API::Photos::search() and so on.
The higher-level concepts-mapping classesThen there are the classes which map concepts such as a user or a photo. As I described in the previous post, these objects should rely on the previous ones to manage the communication with Flickr for them and should implement a representation of all the information that Flickr has on each item.
The way I see it now, the namespace for these objects should be the base Flickr namespace itself and there should exist the following classes:
I've already started writing some code, mainly the tests (aren't I a good little programmer?) and even though I will be away for the weekend on a small family gathering I'll try and have something done by monday when I'll have Internet access again and can try out my code on live data.
(This entry is cross-posted from my personal weblog at
