Last night a friend of mine linked to an article on Rand's In Repose, and naturally I opened up a few tabs to browse his past literary masterpieces. I eventually came across 'The Cave'.
And this got me thinking.
Not about my cave, but about The Place. His Place is World Of Warcraft. (My place certainly isn't a slow running train into London Paddington, but at least I have my precious intorwebnet thanks to my Nokia N95.) I've never got on with WoW. Its never quite felt right to me. Why I (don't) hear you ask? Because I'm still pinning after Ultima Online.
First some backstory of my experience of Vegemites. (A numer of years ago there was an article on Penny Arcade that decided MMOPRG is such an awkward term to use, and advocated using the term Vegemite instead. I agreed with it.Edit: web.archive.org++) I suppose the first MMO that I played was Isengard - a text based MUD - some time around 1997. 1997, when we still had dial-up-modems and had to pay per minute for the telephone calls... luckily my dad also got hooked, so when the quarterly telephone bill came in at around £300, he was equally to blame - thank god.
Around this time Ultime Online was released. And my god did I want. I'd been hooked on the Ultima series since Ultime VI (so much so that I memorized the answers to all the questions that Lord British could ask you.) And Holy of Holies! NTL also had a dial-up service where you didn't have to pay per minute to use it. I was hooked. Origin did indeed Create Worlds.
Back in 1998/9 Ultima Online was a wildly different beast to what it is today - back before EA got thier gubby mits on it. There was just the one facet (Felluca. Each server basically had two copies of the world) - non of this namby-pamby weaker monsters and no PVP that later got introduced when Trammel was introduced.
So what in particular did I like about UO? The crafting. I do think I spent too much time in that game mining near Minoc, or wondering around the forests between Yew and Skara Brae with nothing but a battle axe, some carpentry tools and barely a loin cloth for protection, hoping that I would make it back to my house alive. Yes - player owned housing!
Having a house that you could keep your stuff in, decorate how you want and keep all your possessions in (yes there was a bank like there is in WoW, but it had limited space/weight) was nice, but it wasn't the reason why I would still prefer to play UO than WoW or any of the dozen odd MMOs that I have beta-tested since (me and a housemate at uni went thru a phase of trying to get on every single closed-beta, open-beta, pre-alpha or play test we could).
Its was the leveling system. Or rather the lack of it. WoW you have skills directly related to your level - give or take variations on what skills the player chooses. Ultime Online had no concept of level. No clicking on a person and seeing they are 5 levels lower than you. Each player had a maximum of 700 skill points to distribute as they saw fit among more than around 40 different skills. Want to be proficient with both a sword and with magic? Fine, you can try it. You'd obviously not be as good as a pure mage or a pure fighter due to not having the complementary skills, but you could still kick ass if you did it right.
The other thing I miss about UO that i've not found anywhere else was its Fame and Notoriety system. In UO you'd open the person's paper (or was it papal) doll and see "The Glorious Lady Aliah, Grandmaster Stoic". (She was my guild mistress.) Or "The Dread Lord Azekial, Grandmaster Fighter".
So much more character then "Level 70 Night Elf".
Origin, you truly did create worlds. Then the Destroyer came and pandered to the wimps who complained that they got ganked and had thier silver kryss of power stolen. Didums. You ruined it for all of us.
" --- author: email: ash@firemirror.com keyid: bfc7465ebdca5337 name: Ash Berlin categories: [] date: 2007-09-29T21:58:51Z guid: E6ABD362-6EB3-11DC-8EA1-D6A1BB7FECD7 modified: 2007-11-16T20:22:04Z raw: "I spent most of last week preparing a new server to deploy a project onto a \nnice shiny new [1&1 Dedicated Server](http://www.1and1.co.uk/?k_id=10200518) \n(oh and if you buy something from that link I get a referral bonus - yay!) \nAll the boring stuff like bootstrapping a fresh Debian install onto the \ndisks from a rescue image; fighting the bootloader to make it work with no\nindication of errors when I make a mistake since I have no physical access to\nthe machine - you know: the ususal.\n\nSo once I'd finished those mundane tasks I had to setup the webserver. \nPreviously I'd have gone straight for Apache 2. However I'm deploying a\nCatalyst application to the machine, and although Catalyst will run under\nmod_perl, the recommended method is to use FastCGI since it turns out to be a\nlot less hassle in the long run.\n\n## Aims with FastCGI \n\nWhat I want from my FastCGI deployment:\n\n* to have two seperate FastCGI managers running, so that whenever I need to upgrade the code, I can shut one down, bring it back up with the new code, then do the same for the other - thus giving me the ability to upgrade the code with no downtime (assuming of course that there are no DB changes that might require downtime etc. etc.)\n* to have the static content served via the webserver, since this is what they do well\n* to not have fastcgi show up anywhere in the URL.\n\n## Apache...? \n\n\nDoing this with Apache+mod_fastcgi seems impossible though, since Apache's \nhandling of FastCGI isn't briliant. To do this in Apache you basically have to\ncreate two vhosts (and optionally give them ServerName's that dont resolve\nexternally) and then `Alias / /path/to/fastCGI/N.socket`. \n\nStill with me? 'cos we're not done yet. In the main vhost for the server (i.e. www.myapp.com) you\nthen have to create a [balanced proxy](http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#ProxyPass)\nlike the following:\n\n ProxyPass / balancer://myapp-cluster\n <Proxy balancer://myapp-cluster>\n BalanceMember http://myapp-1.internal\n BalanceMember http://myapp-2.internal\n Allow from all\n Order Allow,Deny\n </Proxy>\n\nComplex, no? And whats worse, is that it doesn't even cope with one of the \nbackend FastCGI servers being down - you just get a 500 page served to the \nuser. Bad Apache! Try the other (FastCGI) server please! \n\n## The Solution - Lighttpd\n\nAfter a bit of Googling, it seems like Apache just wont cope with this \nsituation. I've been hearing good things about Lighttpd, particularly that its\n[FastCGI](http://www.lighttpd.net/documentation/fastcgi.html) support is \nnative and much better.\n\nThe interesting bits of lighttpd config I've used:\n\n lang:perl\n server.moudles += (\n \"mod_alias\",\n \"mod_rewrite\",\n \"mod_redirect\",\n \"mod_setenv\",\n )\n\nPretty self explanatory - load some of the modules we need. The rest of the\nconfig goes inside the `$HTTP[\"host\"] =~ \"www.mysite.com\"` directive.\n\n lang:perl\n # Let lighttpd take care of serving that static content\n alias.url = (\n \"/favicon.ico\" => \"/var/www/mysite.com/MySite/root/favicon.ico\",\n \"/js/\" => \"/var/www/mysite.com/MySite/root/js/\",\n \"/css/\" => \"/var/www/mysite.com/MySite/root/css/\",\n \"/tour/\" => \"/var/www/mysite.com/MySite/root/tour/\",\n )\n\n # rewrite-once will stop processing after the first match\n url.rewrite-once = (\n \"^/((?:js|css|tour)/.*)\" => \"/$1\",\n \"^/favicon.ico\" => \"/favicon.ico\",\n \"^/(.*)\" => \"/fcgi/$1\" \n )\n }\n\nThese two bits tell lighttpd to handle all the static content itself, and \nthen forward everything else off to the /fcgi path, which is defined as \nfollows:\n\n lang:perl\n fastcgi.server = (\n \"/fcgi\" => (\n ( \"host\" => \"127.0.0.1\", \"port\" => 3010, \"check-local\" => \"disable\"),\n ( \"host\" => \"127.0.0.1\", \"port\" => 3011, \"check-local\" => \"disable\")\n )\n )\n \nFairly obvious - everything under `/fcgi` is handled by the FastCGI servers.\nNote however that this will make Catalyst think it is based at \n`http://mysite.com/fcgi/` which it isn't, so we need to fix it:\n\n lang:perl\n $HTTP[\"url\"] =~ \"^/\" {\n setenv.add-environment = ( \"SCRIPT_NAME\" => \"/\" )\n }\n\nThat does the job - Catalyst now thinks its rooted at `/`, and lighttpd is now\nhandling all the static content itself.\n\nFor the completeness-sake, I've included the full config as a single block \nbelow.\n\n lang:perl\n $HTTP[\"host\"] =~ \"^mysite.com\" {\n url.redirect = ( \"^/(.*)\" => \"http://www.mysite.com/$1\" )\n }\n\n $HTTP[\"host\"] =~ \"www.mysite.com\" {\n\n # dir listings are bad\n server.dir-listing = \"disable\"\n\n server.errorlog = \"/var/log/lighttpd/mysite.com.error.log\"\n accesslog.filename = \"/var/log/lighttpd/mysite.com.access.log\"\n\n # Let lighttpd take care of serving that static content\n alias.url = (\n \"/favicon.ico\" => \"/var/www/mysite.com/MySite/root/favicon.ico\",\n \"/js/\" => \"/var/www/mysite.com/MySite/root/js/\",\n \"/css/\" => \"/var/www/mysite.com/MySite/root/css/\",\n \"/tour/\" => \"/var/www/mysite.com/MySite/root/tour/\",\n )\n\n # rewrite-once will stop processing after the first match\n url.rewrite-once = (\n \"^/((?:js|css|tour)/.*)\" => \"/$1\",\n \"^/favicon.ico\" => \"/favicon.ico\",\n \"^/(.*)\" => \"/fcgi/$1\" \n )\n\n fastcgi.server = (\n \"/fcgi\" => (\n ( \"host\" => \"127.0.0.1\", \"port\" => 3010, \"check-local\" => \"disable\"),\n ( \"host\" => \"127.0.0.1\", \"port\" => 3011, \"check-local\" => \"disable\")\n )\n )\n\n $HTTP[\"url\"] =~ \"^/\" {\n setenv.add-environment = ( \"SCRIPT_NAME\" => \"/\" )\n }\n\n }\n\n" signed: 1 summary: " I spent most of last week preparing a new …" tags: - lighttpd: 0 - catalyst: 0 - fastcgi: 0 text: "\nI spent most of last week preparing a new server to deploy a project on-\nto a nice shiny new 1&1 Dedicated Server [1] (oh and if you buy some-\nthing from that link I get a referral bonus - yay!) All the boring stuff\nlike bootstrapping a fresh Debian install onto the disks from a rescue\nimage; fighting the bootloader to make it work with no indication of er-\nrors when I make a mistake since I have no physical access to the ma-\nchine - you know: the ususal.\n\nSo once I'd finished those mundane tasks I had to setup the webserver.\nPreviously I'd have gone straight for Apache 2. However I'm deploying a\nCatalyst application to the machine, and although Catalyst will run un-\nder mod_perl, the recommended method is to use FastCGI since it turns\nout to be a lot less hassle in the long run.\n\nAIMS WITH FASTCGI\n\nWhat I want from my FastCGI deployment: to have two seperate FastCGI\nmanagers running, so that whenever I need to upgrade the code, I can\nshut one down, bring it back up with the new code, then do the same for\nthe other - thus giving me the ability to upgrade the code with no down-\ntime (assuming of course that there are no DB changes that might require\ndowntime etc. etc.)to have the static content served via the webserver,\nsince this is what they do wellto not have fastcgi show up anywhere in\nthe URL. APACHE...?\n\nDoing this with Apache+mod_fastcgi seems impossible though, since A-\npache's handling of FastCGI isn't briliant. To do this in Apache you\nbasically have to create two vhosts (and optionally give them\nServerName's that dont resolve externally) and then Alias / /path/to/-\nfastCGI/N.socket.\n\nStill with me? 'cos we're not done yet. In the main vhost for the server\n(i.e. www.myapp.com) you then have to create a balanced proxy [2] like\nthe following:\n\nComplex, no? And whats worse, is that it doesn't even cope with one of\nthe backend FastCGI servers being down - you just get a 500 page served\nto the user. Bad Apache! Try the other (FastCGI) server please!\n\nTHE SOLUTION - LIGHTTPD\n\nAfter a bit of Googling, it seems like Apache just wont cope with this\nsituation. I've been hearing good things about Lighttpd, particularly\nthat its FastCGI [3] support is native and much better.\n\nThe interesting bits of lighttpd config I've used:\n\nPretty self explanatory - load some of the modules we need. The rest of\nthe config goes inside the $HTTP[\"host\"] =~ \"www.mysite.com\" directive.\n\nThese two bits tell lighttpd to handle all the static content itself,\nand then forward everything else off to the /fcgi path, which is defined\nas follows:\n\nFairly obvious - everything under /fcgi is handled by the FastCGI\nservers. Note however that this will make Catalyst think it is based at\nhttp://mysite.com/fcgi/ which it isn't, so we need to fix it:\n\nThat does the job - Catalyst now thinks its rooted at /, and lighttpd is\nnow handling all the static content itself.\n\nFor the completeness-sake, I've included the full config as a single\nblock below.\n\n-- \n [1] http://www.1and1.co.uk/?k_id=10200518\n [2] http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#ProxyPass\n [3] http://www.lighttpd.net/documentation/fastcgi.html\n" title: Catalyst with Lighttpd type: markdown uri: http://perlitist.com/articles/catalyst-with-lighttpd xhtml: "I spent most of last week preparing a new server to deploy a project onto a nice shiny new 1&1 Dedicated Server (oh and if you buy something from that link I get a referral bonus - yay!) All the boring stuff like bootstrapping a fresh Debian install onto the disks from a rescue image; fighting the bootloader to make it work with no indication of errors when I make a mistake since I have no physical access to the machine - you know: the ususal.
So once I'd finished those mundane tasks I had to setup the webserver. Previously I'd have gone straight for Apache 2. However I'm deploying a Catalyst application to the machine, and although Catalyst will run under mod_perl, the recommended method is to use FastCGI since it turns out to be a lot less hassle in the long run.
What I want from my FastCGI deployment:
Doing this with Apache+mod_fastcgi seems impossible though, since Apache's handling of FastCGI isn't briliant. To do this in Apache you basically have to create two vhosts (and optionally give them ServerName's that dont resolve externally) and then Alias / /path/to/fastCGI/N.socket.
Still with me? 'cos we're not done yet. In the main vhost for the server (i.e. www.myapp.com) you then have to create a balanced proxy like the following:
ProxyPass / balancer://myapp-cluster\n<Proxy balancer://myapp-cluster>\n BalanceMember http://myapp-1.internal\n BalanceMember http://myapp-2.internal\n Allow from all\n Order Allow,Deny\n</Proxy>\nComplex, no? And whats worse, is that it doesn't even cope with one of the backend FastCGI servers being down - you just get a 500 page served to the user. Bad Apache! Try the other (FastCGI) server please!
After a bit of Googling, it seems like Apache just wont cope with this situation. I've been hearing good things about Lighttpd, particularly that its FastCGI support is native and much better.
The interesting bits of lighttpd config I've used:
server.moudles += (\n "mod_alias",\n "mod_rewrite",\n "mod_redirect",\n "mod_setenv",\n)\nPretty self explanatory - load some of the modules we need. The rest of the config goes inside the $HTTP["host"] =~ "www.mysite.com" directive.
# Let lighttpd take care of serving that static content\n alias.url = (\n "/favicon.ico" => "/var/www/mysite.com/MySite/root/favicon.ico",\n "/js/" => "/var/www/mysite.com/MySite/root/js/",\n "/css/" => "/var/www/mysite.com/MySite/root/css/",\n "/tour/" => "/var/www/mysite.com/MySite/root/tour/",\n )\n\n # rewrite-once will stop processing after the first match\n url.rewrite-once = (\n "^/((?:js|css|tour)/.*)" => "/$1",\n "^/favicon.ico" => "/favicon.ico",\n "^/(.*)" => "/fcgi/$1" \n )\n}\nThese two bits tell lighttpd to handle all the static content itself, and then forward everything else off to the /fcgi path, which is defined as follows:
fastcgi.server = (\n "/fcgi" => (\n ( "host" => "127.0.0.1", "port" => 3010, "check-local" => "disable"),\n ( "host" => "127.0.0.1", "port" => 3011, "check-local" => "disable")\n )\n )\nFairly obvious - everything under /fcgi is handled by the FastCGI servers. Note however that this will make Catalyst think it is based at http://mysite.com/fcgi/ which it isn't, so we need to fix it:
$HTTP["url"] =~ "^/" {\n setenv.add-environment = ( "SCRIPT_NAME" => "/" )\n }\nThat does the job - Catalyst now thinks its rooted at /, and lighttpd is now handling all the static content itself.
For the completeness-sake, I've included the full config as a single block below.
$HTTP["host"] =~ "^mysite.com" {\n url.redirect = ( "^/(.*)" => "http://www.mysite.com/$1" )\n}\n\n$HTTP["host"] =~ "www.mysite.com" {\n\n # dir listings are bad\n server.dir-listing = "disable"\n\n server.errorlog = "/var/log/lighttpd/mysite.com.error.log"\n accesslog.filename = "/var/log/lighttpd/mysite.com.access.log"\n\n # Let lighttpd take care of serving that static content\n alias.url = (\n "/favicon.ico" => "/var/www/mysite.com/MySite/root/favicon.ico",\n "/js/" => "/var/www/mysite.com/MySite/root/js/",\n "/css/" => "/var/www/mysite.com/MySite/root/css/",\n "/tour/" => "/var/www/mysite.com/MySite/root/tour/",\n )\n\n # rewrite-once will stop processing after the first match\n url.rewrite-once = (\n "^/((?:js|css|tour)/.*)" => "/$1",\n "^/favicon.ico" => "/favicon.ico",\n "^/(.*)" => "/fcgi/$1" \n )\n\n fastcgi.server = (\n "/fcgi" => (\n ( "host" => "127.0.0.1", "port" => 3010, "check-local" => "disable"),\n ( "host" => "127.0.0.1", "port" => 3011, "check-local" => "disable")\n )\n )\n\n $HTTP["url"] =~ "^/" {\n setenv.add-environment = ( "SCRIPT_NAME" => "/" )\n }\n\n}\nLast week at YAPC::EU I saw a few interesting talks, including Stevan's Moose introduction. I found this talk really helpful, maybe in part because I had read through Moose's documentation and cookbook examples once a month or so ago.
So I wanted to learn Moose a bit better, and I'm a firm believer of learning new technologies by actually writing something using them, so I needed a project - not to complex, but also not trivial. And I had just the thing - something I made a start on in June, but sadly only ever existed on my laptop that got stolen. I present the following code snippet for consideration taken from a test suite at work:
my $mech = WWW::Mechanize->new;\n\nok( $mech->get("$base/index") );\nok( $mech->content =~ m{<div id="header">Welcome To My Site</div>} );\nWhat's wrong with it? Well for a start, it should be using Test::WWW::Mechanize which fixes a few problems. But its still parsing XHTML (you do write XHTML web sites don't you.) using a regexp, which is always a bad idea. What happens if you change the ID of the element, or add a class to it? It'll stop working and your tests will break. My solution? WWW::Mechanize::TreeBuilder:
my $mech = Test::WWW::Mechanize->new;\nWWW::Mechanize::TreeBuilder->meta->apply($mech);\n\n$mech->get_ok("$base/index");\nis( $mech->look_down(_tag => 'div', id => 'header')->as_trimmed_text, 'Welcome To My Site');\nMuch better.
" --- author: email: ash@firemirror.com keyid: bfc7465ebdca5337 name: Ash Berlin categories: [] date: 2007-07-30T10:08:34Z guid: 0B9DEC2E-3E84-11DC-866F-CDAFE7958AD2 modified: 2007-07-30T10:08:34Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nPlease direct all questions about Fotango to Gina Jones, European Corporate Public Relations Manager at Canon Europe (Ph +44 (0) 208 588 8000).\n\nThat is all.\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.7 (Darwin)\n\niD8DBQFGrbiPv8dGXr3KUzcRAmzCAJ4ulnJpuQo8sA9tlV12Dod3T2+M9wCfSuMO\nRjlG4Z1bpZ8xbl0vCVi3KQ0=\n=8U1W\n-----END PGP SIGNATURE-----\n" signed: 1 summary: "Please direct all questions about Fotango to Gina Jones, European …" tags: - fotango: 0 - canon: 0 text: "Please direct all questions about Fotango to Gina Jones, European Corpo-\nrate Public Relations Manager at Canon Europe (Ph +44 (0) 208 588 8000).\n\nThat is all.\n" title: Fotango type: text uri: http://perlitist.com/articles/fotango xhtml:Please direct all questions about Fotango to Gina Jones, European Corporate Public Relations Manager at Canon Europe (Ph +44 (0) 208 588 8000).
That is all.
--- author: email: ash@firemirror.com keyid: bfc7465ebdca5337 name: Ash Berlin categories: [] date: 2007-07-26T10:21:22Z guid: B532CCCE-3B5E-11DC-951E-B900E57C4965 modified: 2007-07-26T10:21:22Z raw: "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n=pod\n\nSo in a bit of down time today between projects, a colleague was working on\nmodifying his blog to syndicate photos from Vox, instead of using flickr as he\ncurrently does.\n\nBelow is the perl code he used to extract the photos and associated meta-data\nfrom the Atom feed the Vox publish. It uses the best (i.e. fully featured and\ncompliant) perl XML parser available - XML::LibXML. Take a look at the\nfollowing:\n\n lang:Perl\n my $parser = XML::LibXML->new();\n\n my $xpc = XML::LibXML::XPathContext->new;\n $xpc->registerNs('atom', 'http://www.w3.org/2005/Atom');\n\n my $library = $parser->parse_file( $library_file )->documentElement();\n my $entries = $xpc->find('/atom:feed/atom:entry',$library);\n\n for my $entry ( $entries->get_nodelist ) {\n my $data = { \n map { \n $_ => $xpc->findvalue('atom:'.$_, $entry)\n } qw( id title content published )\n };\n\n my $link = $xpc->findvalue('atom:link[ @rel = \"alternate\" ]/@href', $entry);\n \n # Do stuff with the photo now...\n }\n\nThe code is a bit... verbose. Or rather it seems like it should be possible to\nmake it cleaner. But its not really - this is just how you have to process\nthat XML to get the required data out. (Just to be clear, this is in no part a\ndig at Vox's atom layout.)\n\nIn glancing over his shoulder and wincing, we both agreed that it is in\nsituations like this that E4X really comes into its own. Don't believe me?\nWell then consider the following JavaScript code which does the same as the\nabove perl fragment.\n\n lang:JavaScript\n default xml namespace = 'http://www.w3.org/2005/Atom';\n var entries = new XML(library_file)..entry;\n \n for each (let entry in entries.*) {\n var data = { };\n for each (let key in ['id', 'title', 'content', 'published'] )\n data[key] = entry[key];\n \n link = entry.link.(@rel=\"alternate\").@href;\n \n // Do stuff with link and data\n }\n\nMuch cleaner and easier to see what's going on isn't it? Not only that but its\nabout half as many lines. If that was all that needed doing, then JavaScript\nwould have been perfect for the job. Sadly, this was not the case - the next\nstep alluded to by the CSo in a bit of down time today between projects, a colleague was working on\nmodifying his blog to syndicate photos from Vox, instead of using flickr as he\ncurrently does.
\nBelow is the perl code he used to extract the photos and associated meta-data\nfrom the Atom feed the Vox publish. It uses the best (i.e. fully featured and\ncompliant) perl XML parser available - XML::LibXML. Take a look at the\nfollowing:
\nmy $parser = XML::LibXML->new();\n\nmy $xpc = XML::LibXML::XPathContext->new;\n$xpc->registerNs('atom', 'http://www.w3.org/2005/Atom');\n\nmy $library = $parser->parse_file( $library_file )->documentElement();\nmy $entries = $xpc->find('/atom:feed/atom:entry',$library);\n\nfor my $entry ( $entries->get_nodelist ) {\n my $data = { \n map { \n $_ => $xpc->findvalue('atom:'.$_, $entry)\n } qw( id title content published )\n };\n\n my $link = $xpc->findvalue('atom:link[ @rel = "alternate" ]/@href', $entry);\n \n\n # Do stuff with the photo now...\n}\n\n
The code is a bit... verbose. Or rather it seems like it should be possible to\nmake it cleaner. But its not really - this is just how you have to process\nthat XML to get the required data out. (Just to be clear, this is in no part a\ndig at Vox's atom layout.)
\nIn glancing over his shoulder and wincing, we both agreed that it is in\nsituations like this that E4X really comes into its own. Don't believe me?\nWell then consider the following JavaScript code which does the same as the\nabove perl fragment.
\ndefault xml namespace = 'http://www.w3.org/2005/Atom';\nvar entries = new XML(library_file)..entry;\n \n\nfor each (let entry in entries.*) {\n var data = { };\n for each (let key in ['id', 'title', 'content', 'published'] )\n data[key] = entry[key];\n \n\n link = entry.link.(@rel="alternate").@href;\n \n\n // Do stuff with link and data\n}\n\n
Much cleaner and easier to see what's going on isn't it? Not only that but its\nabout half as many lines. If that was all that needed doing, then JavaScript\nwould have been perfect for the job. Sadly, this was not the case - the next\nstep alluded to by the Do stuff with link and data comment involves\ndownloading the image and creating a thumbnail of it. Not possible with\nserver-side JavaScript. Yet.
As I mentioned in a post about\nmod_js\ncreating a JavaScript target for SWIG seemed like a good idea. It still does.\nWe looked at Helma - a Rhino/Java based server-side\nJavaScript platform. It looks good, it really does.
\nHowever to me, I would be slightly loathe to use it for three reasons:
\n[a,b] = [1,2]\n\n
Back to the point of SWIG, Helma should be able to use SWIG since you can\ngenerate wrappers for Java already. Saying that, the need to use SWIG with it\nis reduced since you can (I assume) use native Java.
\nBut I would still like the ability to use SWIG from Spidermonkey, my JS\nEngine of choice. Watch this space - I'll be working on it.\n
\n\n\n