After hosting my humble website with a local company for more than four years, I have decided to move to a new hosting provider who offers a lot more features and consequently a lot more exciting opportunities for me to screw things up.

In a couple of days, spicynoodles.net should resolve to this website too and all old links will hopefully keep working, including the URL for my RSS feed. If you stumble across any broken links, please let me know.

Who knows, maybe I will even get around to updating this site a little more often than during the last few years.

Over the last few months, I noticed a few requests for an XSLT processor that would run in Frontier and Radio. After experimenting with both the Apache XML project’s Xerces / Xalan and the Gnome project’s libxml / libxslt libraries, I finally managed to produce a working extension for Frontier and Radio based on the Ginger Alliance’s Sablotron:

To install, unpack the archive and open the resulting file with Frontier or Radio.

Please note: This release is for thrill seekers only. It is neither feature-complete nor fully debugged. I have done some light testing on Mac OS X and Windows 2000, but the Mac OS Classic version has not been tested at all. If this release blows up your machine, I will not accept any responsibility.

The DLLs shipping with this release log a lot of internal information to a text file named “sablotron_dbg_log.txt” that might end up in your Frontier or Radio folder or whatever happens to be the current working directory.

The processor currently ignores any encoding specified in the stylesheet for the output document as Sablotron only supports UTF-8 natively for output. Support for other common encodings will of course be added later.

There is only minimal documentation in the form of a sample script at sablot.examples.transformTest.

Finally, it is entirely possible that there will be some fundamental changes to the API over the next few releases that will break all scripts written to the current API. You have been warned.

That said, I am very interested in any kind of feedback from anyone who dares to experiment with this release.

Since the last public release, I fixed a bug in the Mac OS X networking code that would block all Frontier threads while the extension was waiting for a response from the server after submitting a query for execution.

As a side effect of the fix, it is now possible to abort calls into the verbs for executing queries and retrieving multiple/all rows of a result set via the usual cmd/ctrl-period mechanism (or the Kill button of a script window). This will send a request to the server asking it to cancel the current query and close the network connection cleanly, but it will not deallocate all resources associated with the connection on the client side.

This update is strongly recommended for anyone using the extension on Mac OS X. While the original blocking behavior only manifested itself on Mac OS X, the ability to kill queries was also implemted for the Mac OS Classic and Windows versions.

The only change since 1.0a10 consists of a fix for an infinite loop bug in the connection pooling logic. Once the time specified by the restartTimeoutSecs parameter of the postgreSQL.pool.create verb had run out, the extension would continuously close and re-open a connection to the database server.

This update is strongly recommended for anyone using the connection pooling feature of the extension.

A couple of days ago, Bill Humphries posted a request for an XSLT processor on the Frontier-Users mailing list.

Yesterday, I started working on such a DLL for Frontier (and Radio) based on the Gnome project’s libxml2 and libxslt libraries. Earlier today, I managed to apply an XSL stylesheet to an XML document from inside Frontier for the first time.

The whole project is still at the proof-of-concept stage. Exposing a fully functional interface to UserTalk scripts will take a bit of work—but so far things look promising

Implemented an easier-to-use high-level interface for executing queries and retrieving query results, loosely based on the Python Database API Specification 2.0. Query parameters and result sets are converted transparently between UserTalk and PostgreSQL data types and vice versa. All new verbs are documented in DocServer format.

Implemented connection pooling: The extension optionally manages a pool of connections to the database backend for you. When you need a connection, you can just grab an idle connection from the pool instead of opening a new one, thereby eliminating the overhead associated with opening the TCP/IP connection, authenticating, and starting up a new backend process on the server.

Upgraded PostgreSQL front-end library code from 7.1.2 to 7.2.

Cleaned up the extensions.postgreSQL table by moving all verbs making up the old libpq interface out of the way into the postgreSQL.PQ sub-table.

If you give this version a try, please let me know how it goes. I’m especially interested in feedback about the design and usability of the new high-level interface.

You have come to the right place, except the documentation for my PostgreSQL extension has not been written yet. However, that is going to change until the next version, scheduled for release later this week. This version will implement connection pooling and an easier-to-use high-level interface for executing queries and obtaining query results.