Open Source Notes, Wiki, Forums. We Proudly Use Debian GNU/Linux
Today I spent a few hours digging into Ruby. I’ve tried it out a few times before, but barely scratched the surface. Its nice. Feels like a friendlier python.
I’m trying out the libxml2 and libxslt bindings, and they are very straightforward, but I haven’t yet figured out how to transform a libxml2 object without first serializing it. There has got to be a way…
Debian (which is awesome) has the aolserver4-nsxml package, but it doesn’t come with xslt support compiled in. So I’ve downloaded the source and am trying to build it with xslt support. In the Makefile:
ifdef LIBXSLT
MODLIBS = -L/usr/lib -L/usr/lib -lxml2 -lxslt
CFLAGS += -DDO_XSLT -I$(LIBXML2)/include/libxml2 -I$(LIBXSLT)/include
else
MODLIBS = -L/usr/lib -lxml2
CFLAGS += -I/usr/include/libxml2
endif
Hmmm, not sure how to work with that, maybe I’ll just set LIBXSLT to the path where its located?
I set LIBXSLT = /usr, and that seems to make it try to compile in xsl support, but I get these compilation errors:
nsxml.c:2240: warning: implicit declaration of function ‘xmlMemSetup’ nsxml.c:2240: error: ‘xmlFreeFunc’ undeclared (first use in this function) nsxml.c:2240: error: expected ‘)’ before ‘ns_free’ nsxml.c:2245: warning: implicit declaration of function ‘xmlInitMemory’ nsxml.c:2247: warning: implicit declaration of function ‘xmlSetExternalEntityLoader’ nsxml.c:2247: error: ‘xml_load_entity’ undeclared (first use in this function) nsxml.c:2249: warning: implicit declaration of function ‘xmlInitParser’ nsxml.c:2251: warning: implicit declaration of function ‘xmlSubstituteEntitiesDefault’ nsxml.c:2252: error: too many arguments to function ‘xsltSetGenericErrorFunc’ make: *** [nsxml.o] Error 1
Sweet! I somehow got it to work just by trying a few different attempts! Here’s what worked:
#
# $Header: /cvsroot/aolserver/nsxml/Makefile,v 1.3 2002/06/01 17:30:24 scottg Exp $
#
# nsxml --
#
# Implements XML parser
#
ifdef INST
NSHOME ?= $(INST)
else
NSHOME ?= /usr/lib/aolserver4
endif
LIBXML2 = /usr
LIBXSLT = /usr
MOD = nsxml.so
OBJS = nsxml.o
HDRS =
ifdef LIBXSLT
MODLIBS = -L/usr/lib -lxml2 -lxslt
CFLAGS += -DDO_XSLT -I/usr/include/libxml2 -I/usr/include
else
MODLIBS = -L/usr/lib -lxml2
CFLAGS += -I/usr/include/libxml2
endif
include $(NSHOME)/Makefile.module
install:
mv *.so debian/nsxml/usr/lib/aolserver4/bin/
.PHONY: install
This is very very cool! 
TODO: Add support for parsing XSLT files - this is an absolute must as most xsl templates use imports and includes these days.
I’ve been searching for XSLT bindings for Erlang, and though hard to find, there are some projects out there:
Every once in a while, someone’s PHP bashing gets the best of me, and I review some other languages: python, ruby, ocaml, perl, and c mostly. I’ve dabbled a bit with most except ocaml, and I don’t really have a preference. I started using PHP based upon a suggestion from a friend of mine many years ago, and just kept going because it was the path of least resistance.
Amongst the interpreted languages, I’ve tried out python, perl, and ruby all with reasonable success, and so I’m pretty much planning to continuing to use them all as the situation dictates. Its probably a good idea to be flexible like that.
So how am I feeling about situation dictation?
I’m feeling that python is good when you want to hunker down and build a big sophisticated program which can do everything on its own pretty well. The pluses - wsgi, cross platform, awesome community. The downsides (for me), the barrier to entry is still a little high. Its definitely more of a real programming language than perl or php, which can be scripted and run without too much specificity. I’m still at the plowing ahead stage of programming, not so much as the plan-before-build stage. For me, its a lot about convenience. I really like how python can run as a daemon and keep accounting of things - like with fail2ban. That’s the kicker for me, if I were to create a monitoring system which needed to keep track of changing dynamics, I’d use python.
I like perl. Its a lot like php in the its easy to get going. Its readily available, has an awesome community, and has tons of libraries out there. However, like python, it lives just outside the web world for me, back in the command line, shell world. Now that I’m using mod_fcgid instead of mod_php, that is less true, but I still have a bit of a tough time using either python and perl with apache.
What’s impressed me so much about perl is the work that brad fitzpatrick has done with it - like memcached and djabberd, as well as the spamassassin project. The mod_perl community is also really impressive. There are some pretty amazing mod_perl modules out there, and I’m impressed with how well they work with Apache.
I guess if I were to create a network socket server or an apache module prototype, I’d use perl.
Of perl, python, and ruby, I’m least familiar with ruby. I’ve used it on the command line and it seems to have some cool stuff and a good community, so I’m sure I’ll be using more of it. Ruby appears to have a lot of web use cases, but I’ve missed the boat in that regard. Mongrels and ruby on rails is foreign to me, but I’m definitely interested. The RoR stuff and MVC reminds me of Java, which doesn’t thrill me. I’d rather write in C, and only concern myself with running the code on free operating systems like FreeBSD and GNU/Linux.
So what about PHP? Well as I’ve said before, I don’t really write much in PHP. I maintain Nexista, but most of the applications which run on it are written in XML, XSLT, and SQL, leveraging the libxml2 and libxslt libraries which have PHP bindings.
Inasmuch, I’ve thought a lot about rewriting Nexista as an optimized Apache application server, and I might just do that someday. I’ve started on a python port, but haven’t made it too far. It might be possible to get parts of it working on Apache using existing modules like mod_sqil and mod_xslt, and then fill in the gaps with customized c-based modules, or maybe ever mod_perl modules.