Editorial
“Cyberspace. A consensual hallucination experienced daily
by billions of legitimate operators, in every nation, by
children being taught mathematical concepts… A graphic
representation of data abstracted from the banks of every
computer in the human system. Unthinkable complexity.
Lines of light ranged in the non space of the mind, clusters
and constellations of data. Like city lights, receding....”
William Gibson - Neuromancer
A lot has happened since the early days of the World Wide Web explosion: the protocols have evolved, new ones have been introduced, the mark-up languages have changed, the support tools have matured and have become at the same time more accessible and more complex. One of the practical consequences is that ten years ago a surfer of the new virtual wave had to work hard to find a way to put his hands on a Web Browser, no matter which platform or Operating System he was using, whereas today he would hardly find an OS whose standard installation package does not include a full-featured Web Browser. That’s certainly good news for software developers. There are many who think that a Web Browser like Microsoft’s Internet Explorer or Mozilla are powerful enough platforms to build and deliver full-fledged applications on, and there are many good examples of such applications. In fact for those who have the luck of a permanent and fast Internet connection, the boundary between local computing and remote computing is becoming fuzzier. I will only mention in passing the new challenges that this kind of exposure poses in terms of security and privacy, because what I want to concentrate on are the actual technical benefits of using a Web Browser and a Web Server as the means to build an application’s GUI front?end.
Let us start from the browser. The series of articles by Adrian Smith that Vector hosted in the past should have convinced our readers that HTML is really simple and that, even if not suited to all kinds of data entry, it can be used to represent information in a possibly primitive but effective way. The quality of the presentation can be readily improved using the so-called Cascading Style Sheets (CSS to friends). I’ll also happily fly over the headaches that some cross-browser incompatibilities can cause because my goal here is not to describe a public Web Application (like Amazon’s web site, or Yahoo’s portals) but a specialised front-end, therefore I can make assumptions about the platforms my GUI will run on.
So, with a few angular brackets, our data is beautifully laid out and we can now look at the way things look back-stage. Amongst the empty crates of beer, the wasteland of used tea filters (sorry, I don’t drink coffee), there sits the mighty Server. The image is purely metaphorical, of course, since, as I said earlier, our application will not run on a dedicated server at our headquarters, but will be shipped at the customer’s site, and I am sure we’ve all experienced the chilling (truly freezing) beauty and neatness of a customer’s equipment’s vault. Since we are APLers, our data will probably be generated by the clever one-liner we are so proud of. The question is: how do we get it to appear, beautifully formatted in HTML inside the final user’s browser? Here is where the big distinctions need to be made in my opinion: it really depends on the kind of data, on the kind of network infrastructure on which the application is deployed, on the expected load, on the required levels of security. Writing a simple (crude) HTTP server is an afternoon’s divertissement. To make it safe, fully compliant, fast and scalable is a lifetime’s occupation, and it may very well require a degree of intimacy with the TCP socket layer of the host machine which some programming languages don’t permit, and APL is no exception. If we envisage heavy load and sophisticated client requirements, we will be better off choosing the released work of those people who have spent the mentioned lifetimes and provided us with powerful all-singing and all-dancing HTTP servers. The only problem left would be to interface our computing engine with the distributing server. Easier said than done, once again, but APL is at no particular disadvantage when compared to other languages. Possibly we could be slowed down only by a lack of publicly available samples to build on, but one can always borrow ideas.
Still, there are situations where our crude APL-based HTTP server can be useful. Let us concentrate on a very precise example: instrumentation of an application server, like a proprietary database engine or an intelligent data cache. Some might consider it a waste of time but my experience in the field tells me that what is known as instrumenting a server is quite useful. It seems to be a nature’s law that customers are really good at creating problems that all our cleverly designed lab tests did not catch, and their IT infrastructure is no better: flaky networks, shady hardware, unexpected usage scenarios, our nightmares becoming reality. Sometimes it is a real lifesaver to have the possibility of monitoring the inner workings of an application server, even to do simple maintenance without disturbing the users connected to it, users who are not the least concerned about our technical problems and only want to get their jobs done, switch off their PCs on their way out of the office and enjoy this kind Spring sun. Here is where an embedded HTTP server comes to our rescue. Since such a server is hosted directly by the process running the application, it has access to all of its internal states and can even control it. Useful statistics can be collected based on this privileged knowledge and they can be analysed in real-time to keep the server healthy. Why use an HTML front-end? First, as we said earlier, producing HTML is simple and we can leave all the gory details of the formatting of text paragraphs, data tables and graphs to the Web Browser. Second, the system administrator at the customer’s site won’t need to install anything in order to access our application monitor. Third, anything that has to do with trendy technologies will have a stronger selling impact, and will please both financial and IT managers.
Similarly, whenever there is the need to expose data without involving the main GUI of our application, if the interaction with the user will be mostly in terms of navigation and not so much in terms of data entry, an embedded Web server is an excellent solution. I like to look at this approach as a sort of symbiosis where the embedded server acts as the interface between the original organism and the new partners. So far, my experience with embedded HTTP Servers has been very positive and I certainly plan to keep exploiting and exploring the possibilities of the technology.