NunoNunes.org

Loading
Entries by year
Entries by month
December
Sun Mon Tue Wed Thu Fri Sat
       
13
Powered by Blosxom
Creative Commons License

More thoughts on Flickr API

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 classes

These 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:

  • Flickr::API::People
  • Flickr::API::Photos
  • Flickr::API::Photosets
  • Flickr::API::

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 classes

Then 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:

  • Flickr::Person
  • Flickr::Photo
  • Flickr::Photoset
  • Flickr::

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.

Technorati Tags: ,

About this entry

Originally written on May 13, 2005 @ 21:07
Read article on it's own page (permalink)

First post

Well, it is done: my previous entry made me create my first post on my use Perl; Journal. Cool! :-)

About this entry

Originally written on May 13, 2005 @ 12:41
Read article on it's own page (permalink)

An easier Flickr API in Perl

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->photosgetInfo_ or $flickr->peoplefindByEmail_ 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->photosgetInfo_ 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::peoplefindByEmail()_ or Flickr::API::Methods::photosgetInfo())?
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 feedback. (Hey, I guess this is the first time I explicitly ask for feed-back here… Let’s see how it goes. I should probably start using the use Perl; journal —which I’ve never used at all— for this though… maybe I’ll cross-post there.)

Technorati Tags: ,

About this entry

Originally written on May 13, 2005 @ 12:19
Read article on it's own page (permalink)

So while keeping with my

So while keeping with my latest “keep fit craze” (actually that’s not very correct, it’s more like a “get fit craze” but let’s roll with it), today I went back to my old love —swimming.

Since I’ve been essentially a couch potato for quite a long time now, I decided to get back into it very gently. So I decided to try out the gym’s pool which is only 25m, instead of going for the pool I used to swim at, which is an olympic, 50m pool.

Also I decided to not do a real workout today, but just swim around in the three easy styles and see how I felt and what kind of shape I am in.

And the verdict was really fast to come by, so here it is, together with some notes and comments:

  • The shape I’m in is bad, of course, but not as bad as I expected. It took me almost half an hour to do a measly 1.000m, but I didn’t die doing it, so that’s not so bad;
  • I absolutely need a scheme to follow. If I just go to the pool and see what happens I will muck around and not do anything useful at all. I’ve felt this before, so this is only confirmation of what I already knew. It’s a good thing I kept a record of my workouts from when I was trying (already without great success) to take swimming seriously. I guess I’ll just have to print out some sessions and stick to that for the time being;
  • The 25m pool really breaks your rhythm when you don’t do your turns right. Of course for now it is more than adequate for me, but I need to build my resistance up to the level where I can swim non-stop (including decent turns at the ends of the pool) for a whole 500m or 600m, which where once my warm-up routine. When (if) I get back to that point I may get back to the big pool at Estádio Nacional in Jamor;

About this entry

Originally written on May 13, 2005 @ 10:53
Read article on it's own page (permalink)

The content of this site is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 License.