perlitist.com

So in a bit of down time today between projects, a colleague was working on modifying his blog to syndicate photos from Vox, instead of using flickr as he currently does.

Below is the perl code he used to extract the photos and associated meta-data from the Atom feed the Vox publish. It uses the best (i.e. fully featured and compliant) perl XML parser available - XML::LibXML. Take a look at the following:

my $parser = XML::LibXML->new();

my $xpc = XML::LibXML::XPathContext->new;
$xpc->registerNs('atom', 'http://www.w3.org/2005/Atom');

my $library = $parser->parse_file( $library_file )->documentElement();
my $entries = $xpc->find('/atom:feed/atom:entry',$library);

for my $entry ( $entries->get_nodelist ) {
  my $data = { 
    map { 
     $_ => $xpc->findvalue('atom:'.$_, $entry)
    } qw( id title content published )
  };

  my $link = $xpc->findvalue('atom:link[ @rel = "alternate" ]/@href', $entry);
  

  # Do stuff with the photo now...
}

The code is a bit... verbose. Or rather it seems like it should be possible to make it cleaner. But its not really - this is just how you have to process that XML to get the required data out. (Just to be clear, this is in no part a dig at Vox's atom layout.)

In glancing over his shoulder and wincing, we both agreed that it is in situations like this that E4X really comes into its own. Don't believe me? Well then consider the following JavaScript code which does the same as the above perl fragment.

default xml namespace = 'http://www.w3.org/2005/Atom';
var entries = new XML(library_file)..entry;
 

for each (let entry in entries.*) {
  var data = { };
  for each (let key in ['id', 'title', 'content', 'published'] )
    data[key] = entry[key];
 

  link = entry.link.(@rel="alternate").@href;
 

  // Do stuff with link and data
}

Much cleaner and easier to see what's going on isn't it? Not only that but its about half as many lines. If that was all that needed doing, then JavaScript would have been perfect for the job. Sadly, this was not the case - the next step alluded to by the Do stuff with link and data comment involves downloading the image and creating a thumbnail of it. Not possible with server-side JavaScript. Yet.

As I mentioned in a post about mod_js creating a JavaScript target for SWIG seemed like a good idea. It still does. We looked at Helma - a Rhino/Java based server-side JavaScript platform. It looks good, it really does.

However to me, I would be slightly loathe to use it for three reasons:

• It's Java, and running Tomcat or some other JVM is a bit memory hungry for my co-lo box.
• Rhino isn't quite up-to-date with features that I like using from JavaScript 1.7, such as the following:
  
  

  [a,b] = [1,2]
  

  
  
  While that example is slightly contrived, not having destructive assignment is a bit annoying.
• It's a Framework, not just a platform. This means that if you want to do something that the framework is not designed for, it's either very hard or actually impossible. I've heard that Ruby on Rails also suffers from this problem to some extent. As Tom points out, this is my perlitism coming out again.

Back to the point of SWIG, Helma should be able to use SWIG since you can generate wrappers for Java already. Saying that, the need to use SWIG with it is reduced since you can (I assume) use native Java.

But I would still like the ability to use SWIG from Spidermonkey, my JS Engine of choice. Watch this space - I'll be working on it.