Pytheas & the Problem of Phoenician Tin

One Step Forward, One Step Back

Download 6.56 Mb.
Size6.56 Mb.
1   2   3   4   5   6

One Step Forward, One Step Back

Pytheas was no doubt much wiser in his selection of a language to use in his journey than the first architects of the system named in his honour. There were a number of common dialects for some of the lands that Pytheas would pass on the way to the tin mines and he would have made sure he was as ready to communicate with the inhabitants along the way as he could possibly be. The initial developer’s release of the PYTHEAS system in 1999 was written in several environments. No matter how logical this seemed at the time, it simply confused some of those who wanted to contribute to the project. The first release offered several C libraries, some JavaScript, and Java, as well as PHP for a searching interface. The appropriateness of any of these tools could be argued on its own, but together they made for a strange kind of murky developer’s soup. It quickly became clear that constantly putting on a different kind of developer’s hat to work with PHP for one task, and then C for another, was throwing too much disparate technology into the mix.

For several reasons, Java became the solution to the multiple-language problem. Java tools were available for each part of the project, from establishing a middle layer that could handle multiple connections for staff updates to working with JDBC8 database drivers for loading data into the system. Java also provided a technology called Enterprise Java Beans (EJB) which had the double benefit of both supplying a powerful middleware framework and hiding most of the messy details that had added so much bulk to the original C version of the middle layer. A related and java-based toolkit from Exolab called Castor9 enhances the capabilities of the EJB server while XML10-enabling many of the components of PYTHEAS, which in turn, allowed SOAP/Web Services11 support to be easily incorporated. Finally, Java was one half of a technology originally conceived by Netscape called LiveConnect12, which was an essential component for making the web browser a viable platform for staff client software. The overall architecture of PYTHEAS can be seen in the following diagram.

LiveConnect provides the glue for letting a JavaScript application maximize the power of a web browser, in this case, allowing an applet to hold a stateful connection to a server somewhere on the network (see illustration below). For PYTHEAS’ purposes, LiveConnect also necessitated a fair amount of JavaScript on the browser, as did Mozilla’s XUL (XML User Interface). This somewhat violated the dream of one language for every aspect of the system, but JavaScript is so necessary for utilizing many aspects of a web interface and HTML forms that it looked possible to achieve forgiveness for this deviation from the one language rule. It is hoped to eventually utilize XForms13, the evolving XML-based enhancements to HTML forms in order to provide a rich and flexible editing environment.

Of course, no journey is complete without several interpretations on the optimal route to reach the destination. It seemed unworkable to use a standard web form/cgi-bin setup for the level of updating that would be required for staff to do MARC cataloguing or ordering library materials, yet several observers sent discreet e-mails questioning if the architecture was too complex and “over-engineered” for a library system. Some of the components certainly required the consumption of more caffeine than is recommended for most humans but almost all of the technologies were selected in order to tap into mainstream applications.
In other words, the architecture was designed to maximize contributions from other communities, so that, for example, the general ledger required for Acquisitions could be plugged in using EJB and free up the resources required to develop the ledger from scratch. EJB and SOAP, in particular, free a developer from spending enormous amounts of time implementing tricky programming constructs like transactions and resource pooling.
This did not mean that there were no dilemmas. One very difficult question to answer concerned the goal of using a browser interface for staff clients. It was pointed out that a fully Java-based client could offer a rich interface and a stateful connection, without being tied to a particular platform and with no need to use JavaScript. Still others noted, quite sensibly, that in the library world general scripting languages like Perl might offer some advantages over Java because more developers could be encouraged to contribute.
Pytheas must have reached a point in preparing for his journey that he finalized on a specific direction and sailed into the unknown. The project had already turned back to shore once in order to revamp everything in Java, and the notion of the web browser as a container for application interaction was so compelling that the LiveConnect/JavaScript “deviation” remained part of the architecture. If others build stellar Java clients for PYTHEAS or construct responsive middleware in Perl, then this will be welcomed, but it was time for the project to proceed on to the open waters.

Download 6.56 Mb.

Share with your friends:
1   2   3   4   5   6

The database is protected by copyright © 2023
send message

    Main page