having mucked around a bit more with QR codes i found the excellent QR wordpress plugin from anthony wong — which works really well together with yeo’s wordpress lightbox plugin: if you click on the QR code for this entry link in the header of a blog entry you’ll get an overlay highlighting the QR code for that blog entry, ready to scan (and bookmark) with your mobile phone’s camera!

one of the projects i’m currently working on is the VU*gate system that allows us to write scripts or applications to control an avatar in virtual worlds. VU*gate consists of a gateway daemon “talking” on one side the virtual world network protocol towards the virtual world grid (e.g., for linden lab’s secondlife grid we are using the excellent libsecondlife code) and on the other side a network protocol for which we can easily provide specific language bindings — thus, we can use Java to program virtual world applications (or python or JavaScript or Perl or …).

for the first version of VU*gate (which we then called SLPuppeteer, but that name is already used it transpired) we used a line based protocol modeled on SMTP, enhanced with asynchronous extension (virtual worlds, just like real worlds, are inherent asynchronous). that worked (and still does work) quite well for a lot of things: chatting, instant-messaging, moving about are all easily done with a one line command — and also easily parsed. where this starts to become painful is when you have to deal with more complex data (avatar login including not just fullname and password but also grid URI and location, for example, or group membership data). mind you, VUgate mark 1 is currently in full production use and a perl script is updating the Eightbar SL group¹ via VUgate, using data supplied by our corporate directory Fringe.

clearly, something more structured was what i wanted. preferably with some easy to use libraries taking care of the nitty-gritty details of data serialization and reification. colleagues had suggested switching to REST, but that doesn’t really support asynchronous event reporting (unless you revert to polling, yuck).

the solution i came up with was XMPP, which is the underlying transport protocol for all Jabber based instant messaging services (e.g., googletalk, which is probably the best known of these). after trying the erlang based ejabberd (if you don’t like perl because it looks like an army of flies had reverse bowel movements, you certainly are going to like erlang, yikes) i eventually settled on openfire which’s main merit is that it’s got a rather nice admin web interface and can route messages with custom XML namespaces!

so far, so good — what has all this got to do with perl? well, the current language binding of choice for VUgate is perl (object oriented perl, even), so i wanted to keep the existing perl-based VUgate applications, which meant i needed a perl XMPP stack. turns out there are a couple, the most promising was Net::XMPP. while Net::XMPP played nicely with ejabberd, it definitely did not like Openfire and never managed to even login and, worse, that error (SAX parser flying out of the curve) had been reported and the “fixes” suggested earlier didn’t work anymore. so, chalk one up against good old perl.

next: for asynchronous stuff like VU*gate it would be really nice to use threading in the applications (along with stuff like mutexes, locks, signalling, and so forth). recent perl version claim to support threading…well,

It’s very important to remember when dealing with Perl threads that Perl Threads Are Not X Threads, for all values of X. [perlthrtut]

which is then revealed in the “shared and unshared data” section:

The biggest difference between Perl ithreads and the old 5.005 style threading, or for that matter, to most other threading systems out there, is that by default, no data is shared. [ibid]

hmmmmmm…turns out that you can share some data between threads, but there are some severe restrictions: only simple variables or references to those. no sharing of file descriptors it seems (so, no reader–writer thread separation .

indeed, not what you’d expect.

time to start looking for new stuff…

…time to introduce ourselves to python. it’s has proper threading, and — ta da! — has a proper and non-barfing XMPP stack!

swiss post is issuing a rather special stamp these days — no, not the einsiedeln stamp, though that is special as well (and i need to get a couple of those if just for the christmas post , no, it’s a stamp with a beetagg on it: turns out that swiss post has been secretly posting beetaggs on hiking trail sign posts — by scanning with the beetag reader application you can look up the nearest postbus bus stop along with timetable! quite nice that!

the beetagg system works like tinyurl with 2D barcodes: the tag itself does not contain the URL but rather a unique ID that needs to be resolved via the beetag server — very much like a tiny URL (the tinyURL for this post is http://tinyurl.com/2f9gm9, for example). beetaggs are only available from beetagg themselves — and there is a currently limit of 20 free ones per person not enough by far if i’d like to include the URL of a photo with each photo itself… also, if you read the wiki entry about tinyurls you find in the “criticism” section that

TinyURLs are opaque, hiding the ultimate destination from a web user. This can be used to send people unwittingly to sites that offend their sensibilities, or crash or compromise their computer using browser vulnerabilities. To help combat such abuse, TinyURL allows a user to set a cookie-based preference such that TinyURL stops at the TinyURL website, giving a preview of the final link, when that user clicks TinyURLs.

it seems like beetagg is currently not providing such a feature, so an easy hack would be to paste your own beetag over an already existing one (say, in a shop or so) and send the user’s mobile phone to the JAD file of a surprising application and have it installed…

…or just use the URL used to crash the Apple ipod touch® and the Apple iPhone® >:-)

looking a bit around, i came across QRcodes (as in quick response codes) that have been popular in japan for quite some time it seems, as david harper remarks on his blog:

You might be asking yourself about now, “Gee. I don’t know if people will actually do that?” Well the short answer is – people already do, lots of them in fact. In Japan, for example, QR codes have become part of everyday life, available on everything from business cards, id cards, magazines, newspapers, flyers, posters, stickers, food products,puzzles, web sites, billboards, more billboards, CDs, confectionary delights, calling a cab, vending machines, coffee cups, advertisements, and tickets –- even including the occasional booth-babe [...]

QR codes as it turns out are standardized and software to generate them is freely available. it also looks like QR codes are not 2D barcoded tinyURLs but instead carry the data itself — seems like a better and more open deal then beetagg. there are mobile phone readers available as well (for example, from kaywa, another swiss company — what is it with the swiss and tagging???)

here are the beetagg and the QR code for this blog:

now, if only that new mobile phone would get delivered…(my old motorzr v3 just doesn’t like any of the readers, sigh)