PL/XSLT

Let me introduce the procedural language that you didn't yet know you needed: PL/XSLT.

PL/XSLT isn't actually that new. I faintly recall that I wrote it around the time of the Anniversary Summit in 2006, but never published it. Today I found the source code again, cleaned it up a bit, and put it up on GitHub: http://github.com/petere/plxslt/

Here is roughly how this would look:

CREATE FUNCTION foo(xml) RETURNS xml AS $$
<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xsl="http://www.w3.org/1999/XSL/Transform">
...
</xsl:stylesheet>
$$ LANGUAGE xslt;

There are some conditions on the function definition:

• The first parameter must be of type xml. It will receive the input document. Every function must have at least this one parameter.


• The following function parameters will be supplied to the stylesheet as XSL parameters.


• The return type must match the output method specified by the stylesheet. If it is xml, then the return type must be xml; if it is text or html, the return type must be text or varchar.


• Triggers are not supported.

In the source code, I include an example function that converts the output of the table_to_xml etc. functions to HTML.

Of course, the question will arise whether this is sensible. I guess it is about as sensible as considering XSLT a programming language. Judge for yourself. :-)

In the words of GitHub: fork the project and add to it.

Why I Dumped KDE

I had been a KDE fanboy for about 10 years. I remember compiling version 1.0 from source myself. But now I had to put an end to it. Let this be a lesson to us all. If you produce software that is

1. unstable
2. unintuitive and weird
   
3. lacking important functionality

then your users will be upset.

As a user of free software and Debian testing as my primary desktop operating system, I have a degree of tolerance for unstable software. In fact, two of the biggest culprits in the past, KMail and Konqueror, have become much more stable in KDE 4 compared to KDE 3. But Plasma kept crashing or running nuts with resources, and there were frequent rendering problems that caused windows and icons to disappear, causing me to restart my sessions every so often. I don't need that. And I didn't even dare to stress the enhanced desktop effects (compositing features) beyond a few trials. In the meantime, me and lots of other users who dared to adopt KDE 4.0 or 4.1 had to spend hours reporting interface bugs and regressions that were all probably reported once before but got reintroduced accidentally during the big rewrite.

The second problem was that KDE had set out to reinvent the desktop, and ended up giving users a desktop environment that they did not understand and that they could no longer use in the way they were accustomed to. The new theme and widget style were hard to read and fairly hard to use without the enhanced desktop effects also on. The panels wouldn't stay where I wanted them, and the things on the panels wouldn't either. And why after we have finally gotten to the point that all major free desktop environments can share the system tray, everything in KDE is now a plasma widget that is incompatible with everything else. The widgets, the menus, everything just didn't feel right. The interface of Kopete, the instant messaging client, had me constantly guessing who I was talking to and why. KMail had some good new ideas, but I had to spend hours disabling most new features so I could continue reading my mail. And the network manager applet, still in Debian experimental admittedly, was so weird to use that I'm amazed it ever connected to anything at all.

Which brings me to the third point, the one that finally did it for me. They wrote a new desktop environment, but forgot the include the functionality that people actually need to use. No stable network management. No printer setup. No bluetooth support. No Debian update manager support. The entire groupware suite still cannot synchronize with hardly anything. Not my phone, not Google, not MS Exchange. Instead, there is now a MySQL server running on my desktop with the promise that it will be able to store all my contacts at some point. Or something. And Konqueror, now demoted to merely a web browser, has as far as I can tell, not been developed at all since KDE 3.5. It has serious rendering problems with many currently popular web sites and has none of the extensions that Firefox offers. You can probably synchronize the bookmarks with Akonadi someday. Or something. So, in practical terms, if you subtract all that, you are basically left with nothing, and might as well not use KDE at all.

So what now? I had good experiences with LXDE before, so I went with that. It has worked out well so far: visually appealing, lightweight, yet functional, and you can smoothly mix in KDE and GNOME applications. Well, that's LXDE plus OpenBox, to spread the credit fairly. I got Iceweasel configured to do most of the things that I once appreciated Konqueror for, and with the right extensions it's much better. Evolution isn't as configurable as KMail, but at least it can connect my calendar and addressbook to the external sources that I need. Pidgin gives me more protocol options and a saner interface for instant messaging. I hung on to the KDE konsole application, which has nice enhancements in KDE 4. Also, Amarok, possibly another one of those rewrites/reinventions gone wrong, seems to be without usable alternative at the moment. (Kaffeine has not been ported to KDE 4, and all the Gtk/GNOME-type applications I tried didn't do what I needed them to do.)

The Linux desktop, for lack of a better word, is becoming irrelevant. If you are a hacker, all you really need is a browser and a terminal. And maybe Emacs. If you are a normal user, all you need is a browser and an office suite. And maybe Skype. There is not much room for differentiation left there.

Adding Color to the Console: Round 2: Highlight vs. Pygments vs. Source-highlight

A month ago I compared the Pygments and Source-highlight packages for use as a syntax highlighting tool. A commenter pointed me toward another package called Highlight. So let's compare those three, based on the same criteria as last time:

	Pygments	Source-highlight	Highlight
Debian package	python-pygments	source-highlight	highlight
Dependencies	Python	C++, Boost	C++
License	BSD	GPL 2+	GPL 3+
Input Languages	136	30	143
Output Languages	~11	~6	~9
Styles	16	5	40
Performance test	6 min	64 sec	67 sec

So for interactive use, it looks like a pretty close call between Source-highlight and Highlight, unless you need one of the additional input formats supplied by Highlight. It appears that Highlight supports SGML files out of the box, unlike the other two, which could make it interesting for me.