An up-to-date look at free software and its makers

Projects on the Move

By Peter Kreußel and Martin Loschwitz

Elnur Amikishiyev, Fotolia

Ajax web applications are characterized by ease of use: while browsers have to reload to reflect changes to pages in conventional programs, Ajax (Asynchronous Javascript and XML) based applications retrieve modified data in the background and update only those parts of the page that have actually changed.

More recent Ajax implementations, for example Google's recent acquisition, Writely [1], continue to get closer to the look & feel of desktop programs. Writely uses dialog fields for formatting, giving users the ability to drag the fields to their familiar desktop location in the title bar (Figure 1). And there is a button bar at the top of the page, just like in any other word processor. The program responds without delay when a user presses the »bold« button, for example.

Figure 1: Dialog boxes give the Writely web tool the look and feel of a desktop application.

This does not required asynchronous background downloads (Ajax): Writely uses the browser's design mode instead. In design mode, Mozilla, Firefox, and Opera 9 all provide text input boxes that support formatting, in contrast to fields in standard forms. The Javascript engine can access selected regions and modify font attributes. If you need a Rich Text Editor for you web application, check out the FCK Editor [2], which may well be the most powerful free implementation available under the LGPL.

Variety

Developers are continually attempting to introduce new application types via a web interface. This has given rise to spread sheet applications [3] and a bitmap editor [4], in addition to word processors. Developers have even managed to support vector graphics using just HTML and Javascript: Walter Zorn' vector graphics library [5] implements pixel-sized div layers to be able to render curves, circles, and squares on HTML pages. Although this has very little to do with the original use of the div layer, the approach turns in some pretty useful results under normal working conditions (Figure 2).

Figure 2: The Javascript Vector Graphics Library by Walter Zorn can draw curves and geometrical figures. Because it uses pixel-sized div layers instead of bitmap graphics, graphical elements do not influence the text flow.

Figure 3: Tabs, subwindows, menus, and date browsers for a popular web browser: Dojo saves development effort and cross-browser tests.

McNeal's Dream

In comparison to desktop applications, webtop applications have a number of indisputable advantages: for one, they are independent of the operating system on which the web browser is running. And if a provider gives users access to online storage, along with the Ajax application, you can access both your data and the application required to manipulate them on the web.

Is this long overdue proof of Sun's claim that "The Network is the Computer?" Well, there is at least one point where reality and the vision Sun's long-term CEO, Scott McNeal, published many years ago (for example, in the press release at [6]), couldn't be much farther apart if they tried. McNeal's idea was to "reduce complexity", however, far more development goes into applications such as Writely, or Google Spreadsheets, compared to desktop applications with similar functionality. The underlying technologies (HTML, XML, and Javascript) are not designed for developing complex applications. And developers have often been forced to take roundabout routes to reach their goals.

To avoid ruling out many potential users right from the outset, applications need to go through tests on three or four popular browsers.

The failure of Internet Explorer's Javascript engine to comply with standards often forces developers to code much of the Javascript twice. Thus, it makes a lot of sense to reuse solutions that have been proven to work for future projects. Luckily, there are numerous libraries to help developers implement this fairly recent programming technique.

On Loan

The majority of Ajax libraries contain complex frameworks that provide suitable underpinnings for developing sophisticated applications. The Dojo Toolkit [7] supports simple implementation of widgets such as color pickers, calendars, or even a rich text editor. Form elements such as checkboxes can be dressed with bitmaps; form fields validate input client-side. A tree widget emulates the kind of filesystem trees most file managers provide, and the tab widget helps developers organize controls by topic.

Dojo provides drag & drop support, along with optical effects such as fading in or out. It interates the JSON RPC library to give client-side Javascript code direct access to server-side Java methods.

The Dojo Toolkit abstracts the browser layer (for Mozilla/Firefox, Internet Explorer, Opera, and Safari/Konqueror), thus removing the need for developers to handle the intricacies of disparate Javascript engines.

This ability to abstract the various browsers that might be used with the application speeds up the test process. The demo applications in the "See it in Action" [7] category give you a good idea of the Dojo Toolkit's potential.

Language Barriers

Dojo is implemented in Javascript, and thus not limited to a server-side programming languages. However, if you need to convert a web application into an Ajax application, it is typically preferable to use a wrapper for the language with the existing code.

There are many frameworks that generate Javascript code for Ajax functionality from PHP, in particular. If you are looking for a comprehensive Ajax framework for PHP, check out Prado [8]. The framework is based on the model view controller architecture [9], and helps abstract the page layout from the application logic. Also, there are many toolkits besides the ones I have already referred to ([10], [11]). And new Javascript libraries keep springing up like mushrooms.

Debian has taken the plunge and decided to fork Cdrecord. The new program, dubbed Cdrkit, mainly comprises the last Cdrecord version not released unter the new CDDL license. It remains to be seen if Debian will be able to emancipate the project from Cdrecord author Jörg Schilling [12].

Debconf 7 in Kilts

With the tremors [13] of the last Debconf hardly settled, people are already busy planning for the year 2007. One thing is for certain, the conference will be held in Edinburgh, Scotland. The organizers met for the first time in September to discuss accommodation for participants, how to feed the visitors to the congress, and last but not least the Internet connection.

Visitors to Debconf 2007 can expect some unusual sights with Scots developers promising to have special Debian kilts sewn up to match the venue. I'm really looking forward to seeing the Debian-look kilt (Figure 4).

Figure 4: Developers can don their kilts for Debconf 7 in Edinburgh.

Celebrating Etch

Since the Release Managers, with Debian Project Leader Anthony Towns at their forefront, continue to promise the next Debian release for December 2006, work is still continuing at a frantic pace. A major Bug Squashing Party (BSP) was held in Vienna on the weekend of September 8 through 10. It heralds the start of a BSP Marathon [14], a series of nine parties coming to various European cities in the near future.

For Debian, parties have been a tried and trusted approach to drastically reducing the bug count. What mainly happens is that developers meet, talk about basic steps, and then get down to some collaborative programming. The project even helps third-party maintainers by relaxing the restraints on uploads to the Debian archive, which usually prevent developers from uploading packages for projects they are not responsible for.

Joey Hess ironically protested that Etch was highly detrimental to Debian's reputation. During a test installation, he plugged a USB stick into a USB port, and Etch not only identified the stick but actually set it up so that he could use it. This was not in line with Debian's hotplugging behavior, said Hess.

Automatic Package Building

From time to time, somebody at Debian asks if it wouldn't make more sense to use source-only uploads. In this scenario, Debian developers would simply upload the source code packages for building a Debian package to the Debian archive, and build daemons would handle the build.

The idea behind the concept of source-only uploads is to make it more difficult for attackers to smuggle trojaned binaries into the archive, and at the same time, to make life easier for maintainers of large packages.

Steve Langasek from the Debian Release Team explained that Debian already had support for source-only uploads, although this support has been disabled for a couple of years because it led to developers not testing packages sufficiently prior to uploading the code. Source-only uploads created the problem of too many buggy packages getting passed in to the build process, which then crashed half way through. The extra traffic and waste of CPU time had been unacceptable. This was why, said Langasek, developers were required to do their own building.