Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

gambuzino (4517)

gambuzino
  (email not shown publicly)
http://nunonunes.org/
Yahoo! ID: gambuzinix (Add User, Send Message)
Jabber: gambuzino@jabber.org

Journal of gambuzino (4517)

Friday May 13, 2005
06:37 AM

Thoughts on a new Flickr API for Perl

[ #24665 ]
(This entry is cross-posted from my personal weblog at http://nowhereland.nunonunes.org/archives/2005/05/a_better_flickr.html)

Sooo... Last night Tuxa went to a farewell dinner she and her friends threw for a colleague and I was left home alone without the usual many urgent things to do, so I took a stab at the Flickr modules I'm starting to write.

And now I'm trying to decide which is the better approach to take.

One possible approach would be to create a Flickr object which has a method for each of the Flickr API calls, such as $flickr->photos_getInfo or $flickr->people_findByEmail and so on.
The object should then return a hash structure that closely resembles the documented result for that call, so for example the $flickr->photos_getInfo method (described here) should return something along the lines of the following:

{
  id => "2733",
  secret => "123456",
  server => "12",
  isfavorite => "0",
  license => "3",
  rotation => "90",
  owner => {
             nsid => "12037949754@N01",
             username => "Bees",
             realname => "Cal Henderson",
             location => "Bedford, UK",
           },
  title => "orford_castle_taster",
  description => "hello!",
  visibility => {
                  ispublic => "1",
                  isfriend => "0",
                  isfamily => "0",
                },
  dates => {
             posted => "1100897479",
             taken => "2004-11-19 12:51:19",
             takengranularity="0",
           },
  permissions => {
                   permcomment="3",
                   permaddmeta="2",
                 },
  editability => {
                   cancomment="1",
                   canaddmeta="1",
                 },
  comments => 1,
  notes => [
             {
               id => "313",
               author => "12037949754@N01",
               authorname => "Bees",
               x => "10",
               y="10",
               w="50",
               h="50",
               content => "foo",
             },
           ],
  tags => [
            {
              id => "1234",
              author => "12037949754@N01"
              raw => "woo yay",
              content => "wooyay",
            },
            {
              id => "1235",
              author => "12037949754@N01",
              raw="hoopla",
              content => "hoopla",
            },
          ],
}

This kind of approach appeals to me because it gives me access to just the plain data, in a easy way, without all the XML-parser-generated-cruft, in a much more "perlish" way.

But while I consider this an improvement over the current Flickr::API module (which is great, by the way, and will be used as the foundation for all of this), it may still be too low-level for many people to use.

So there is another possible approach (OK, there are many other possible approaches but I'm focusing one on in particular) ;-) which is to create a set of higher-level objects which represent an entity like a "person" or a "photo" or a "photoset".

Then the user would simply ask the object to instantiate, say, the Flickr user whose email is something@somesuch (using flickr.people.findByEmail on the background) or the photo whose id is someid (using flickr.photos.getInfo). Then, if the user wanted some more information on the photo, for example, she could ask for the lens aperture used ($photo->apperture()) and the object would fetch the EXIF information for the photo in question (using flickr.photos.getExif), load it into the $photo object and return the information.
A major point to make here is that the object would fetch information in a "lazy" manner, so as to limit the number of interactions it has to have with the Flickr server.

My immediate needs are more than adequately met by the first approach to the modules and, therefore, I guess I'll surely implement them right now, but the second approach could be very interesting indeed...
But then, now that I think about it in a more structured way, the second way depends on the first one to process all the results from the raw API and convert them into useful data, so I may well end up implementing it too in the future...

What I haven't figured out just yet is which name-space to use.
Should I go for Flickr::API::Methods (as in Flickr::API::Methods::people_findByEmail() or Flickr::API::Methods::photos_getInfo())?
Or maybe go for Flickr::Tools...
Or I could go with Flickr::Photos (Flickr::Photos::getInfo() for instance), Flickr::People (Flickr::People::findByUsername()). Actually I think I like this last version best...

As for the higher-level modules I'm not entirely convinced they should even be in the Flickr namespace at all... But then I don't have to decide on it just yet so let's see what my mind is aimed at when I get to it.

If anyone reading this has any kind of comment, remark, idea, suggestion or tough about the subject I really would appreciate the feedback.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.