Open Source Contributions

Perl::DBI

Firstly, all credit for the perl DBI goes to Tim (Bunce). Speaking personally, Tim asked if the company would fund perl DBI development work. He explained what a difference it would make in accelerating development for a job for which we were bidding with BT and I agreed. I want to make it clear that my role in the DBI was just that, providing a safe haven where Tim could weave his magic. So in Tim’s words…

Why Write the DBI?

Much of our work involves the development of special custom applications for data acquisition, processing, storage, management, and reporting. As Technical Director, I was responsible for selecting technologies to best fill our clients’ needs. Perl was clearly an excellent tool for us, but to be fully useful it needed to be able to talk to databases.
Since we use whatever database the customer wants, and since we prefer to write reusable data-driven code, one important goal was for any library code we developed to be reusable as part of another system using a different database. In the end, it took about three years to make that a practical reality!

Movin’ on…

Tim left Ingeneering (then the Paul Ingram Group) in April 2001 and moved with his family to Ireland and has continued developing and supporting the perl:DBI ever since. He’s been involved in many other exciting projects, just some of which you can see here. Tim has been presenting at conferences and similar events for over 10 years, which he has thoughtfully uploaded for your delectation here.

JQuery Apache-Soap Client

A common web architecture is a three tier model comprised of the browser, a middleware layer on a front end web server and a WSDL/SOAP backend.

Like many others, we often use jQuery in the web browser communicating with PHP driven middleware talking to a mod perl backend providing a WSDL/SOAP interface using Apache::SOAP and Pod::WSDL.

We wanted to eliminate the middleware so we wrote a jQuery apache-soap client. Using this jQuery API, a browser based application talks securely to backend WSDL driven SOAP services. We used an existing AXIS (Tomcat) specific SOAP client as a basis and reverse engineered the Apache::SOAP specifics into a new client interface.

The two layer model simplifies development as you remove the middleware, a possible point of failure and yet another item to test. It also removes problems that may be introduced by the middleware such as transcoding and data reformatting.

I believe in giving credit where credit is due, so thanks to Jacqui (Caren) for this innovative piece of work.