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 VUgate_ (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 VU*gate, 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!