jamesw: May 2009 Archives

Ok, so I was looking to integrate some perl scripts into my IRC client, which happens to be EPIC, version 4, as EPIC5 seems to be trying to be the Perl6 of the text-mode IRC clients, and I'm not quite there yet (irssi, meanwhile is the Ruby of text-mode IRC clients).  So I was looking for the correct syntax for the perlcall(6) function, (as opposed to the perl(6) and perlxcall(6) functions), and I get this from /HELP 6 perlcall:

*** Help on perlcall

and that was it.  Looking at /usr/local/share/epic/6_Functions/ for perlcall I see it is 0 bytes long.  And so I look and there are 81 files like that.  Shurely Shome mishtake right?  Apparently not, asking in #epic I get informed that I should use the wiki, because 'it makes it a lot easier for us to give you correct/updated information'.  Pathetic, really.  Why can't the documentation be in source control and shipped with the source code?  The online help pages that they have (which aren't categorized, its just a flat dump) could be generated from the text files instead.  But oh no, we need a Wiki for documentation, and must have an internet connection just to read documentation, ugh.  EPIC devs use Unix, right, they aren't hacking the source on their iPhones or Palms. right?

Now, ironically, I will need the perl*call documentation to write a reader of the Wiki documentation so I can use it in EPIC (maybe).  Lovely.  More on that later.

PHP SDK for Windows Azure

So, of course, to show its commitment to open-source, Microsoft has released PHP APIs for Windows Azure.  I'm not sure I understand the love Microsoft has for PHP, but I could be snarky and say the PHP philosophy fits in neatly with Microsoft's languages philosophy. 

Anyway, as much as I wish Microsoft would introduce Perl APIs for Azure, I do not hold out much hope, and instead see this as an opportunity for enterprising Perl coders to outdo the official APIs and increase the number of problem domains where Perl is a possible solution.  The API seems to be mostly HTTP and XML with some extensions (it is Microsoft, after all).  If after completing the other 700 items in my todo list, this is still undone, I'll get right on it.

Also worth noting, re: Azure, is FastCGI support, a definite plus for Perl developers.

So, in summary, Web Apps, REST/XML and FastCGI.  A near perfect fit for Perl, so how did we get to where PHP is the default, first choice language for this? 

Ugh.

So as part of this 'Modern Perl' push, I was looking at KiokuDB for persistence. 

I went through the KiokuDB::Tutorial and kept wondering why the DBI backend did it the way it did: Objects encoded into JSPON blobs, stored in a single field in an 'entries' table, with "indexing" in a separate table. 

I could understand that that probably works well for the BerkeleyDB backend, but putting relational data into a single, essentially unindexable (doing a JOIN from another table with 'index' data doesn't count) blob field is something you really shouldn't be doing in an RDBMS.  Basically it moves data validation and management out of the database where it belongs and into the application (A very Rails-ish way of doing things, and that is a bad thing), and making reporting or other analysis of the data impossible without the additional overhead of a Javascript/JSON library.

So while reading I thought of several alternatives that I would have used instead, mostly PostgreSQL-specific (since that is where I live):

• Using PL/Perl and JSON::Any to create a set of functions for inspecting the JSPON data, which could then provide real indexing with PostgreSQL's functional indexes and make reporting possible without too much overhead on the client;
• Storing the data in XML in an XML field and using PostgreSQL's XML/XPath functions for indexing/reporting on the data;
• Creating a custom type for each persisted class and creating a separate table for each class containing an ID field and a field of that specific type;

Upon thinking of the last one on the list, I realised that since CREATE TABLE actually creates a custom type in PostgeSQL, skipping the whole custom type dance, and just creating a database table for each persisted class would work and be the ideal solution.  Have a mapping between Moose types and SQL types, create references with foreign keys, provide real indexes on single and multivalued types and enable easy integration with other tools for data reporting and analysis.

Sadly, I doubt that Kioku's DBI backend will change at this stage, so I will probably have to write it myself, and will probably remain PostgreSQL-specific for a while.  That is, if I find myself with the need for KiokuDB-level persistence (I usually go from database to code, not the other way round).