Choice of Platform - AustESE-Infrastructure/TILT GitHub Wiki

What platform do we develop the tool on? The constraints would appear to be that this is an open-source project to be developed by digital humanists, and it thus has to use some programming language that many of the potential contributors will be fluent in. It also must be free and open. Proprietary systems are subject to greater changes, and given the investment in time needed to develop things like this the more stable development platforms are to be preferred. Open systems are also free, meaning that there is no barrier of cost.

A second requirement is power and ease of development. The platform has to provide sophisticated graphics manipulation libraries and detailed handling of events, for example, as the mouse moves in and out of regions or as the user clicks on control points to enlarge or create them. Otherwise development will be too slow.

A third requirement is Web delivery. The desktop is more or less dead as a medium for development, in spite of providing mature and powerful means for developing graphically oriented applications. Users will expect to access the tool over the Web, even though this is not strictly necessary. Creating maps between texts and images may be an offline facility, distinct from viewing the results which of course must be online. But providing Web authoring of text-to-image links is likely to be a generally demanded requirement.

This implies two basic strategies:

  1. As a Web application, delivered over the Web and running in the user's browser.

  2. As a server application, user interaction being handled via the Web

The problem with 2 is that the modern trend is towards stateless interactions with the server, i.e. REST. But such a graphical application would need to store the complex state of its current drawing status as the page was being composed. And this state would be user-specific, and there might be several users at the same time. Handling that on the server seems an unnecessary complication. Not to mention of course the complexities arising from sending and receiving mouse-clicks to modify the server's representation.

So that leaves 1. The application and its state exist in the user's browser, and are only saved to the server. This leaves us with few alternatives, because this kind of Web application is not much supported outside of proprietary solutions.

There thus doesn't seem to be any alternative to using Java. Applets are a form of Web application. The drawbacks are that consistent Web delivery on various browsers is problematic, although alleviated by JNLP. Security is also a concern, but can be reduced by signing applets. Java has the power to do what we need to do, it is free and open, it is understood by the majority of digital humanists and it has Web delivery. It is also very easy to develop in.

The only other option appears to be javascript, but the lack of graphics image libraries is the problem here. It doesn't have mature tools even for drawing regions let alone manipulating images. TILE tried this approach and ran into difficulties for these very reasons.

C/C++ has the power and the graphics libraries, but not the Web delivery. It is desktop-oriented and is not widely used by digital humanists. All other web-delivery platforms (e.g. Silverlight, Flash) are proprietary. HTML5 doesn't do interaction.

Modern scripting languages like ruby or python don't run reliably in the browser yet, and don't have the necessary speed or graphics libraries.

TILT is already in Java, and changing to another development platform will be costly. So unless someone can argue otherwise, Java it will be.

To make things easier the project will be maintained in both Eclipse and NetBeans formats. Again, these are freely available and work well.