DevelopmentPhilosophy

This page provides some more detail on the development philosophy behind the project, the underlying motivations for that philosophy, and the role in the bigger picture of the portion you can find here on SourceForge.

Earliest history

First, the history behind the project. A detailed description of how and why it started, roundabouts 2006, can be found at http://www.dcs.warwick.ac.uk/~hugh/TTM/Reflections-from-implementers.html#SIRA_PRISE . That article was dated roundabouts 2010, and was written as an invited contribution to the book entitled "Database Explorations", by Date&Darwen (all known implementers received such an invitation, and many responded - you'll find the other contributions on the same page). Ultimately, for various reasons, none of those invited contributions were actually included in the book, instead they were published on the web site.

At the outset, I made the conscious choice that SIRA_PRISE would have to be "from the ground up", starting at absolute zero. Tabula rasa with SQL, clean sheet development. This choice was made primarily for the server component, but it carried over quite naturally to everything in the client side ecosystem. After all, if you consicously decide to just plain forget about SQL because of all its violations of the RM, how can you opt for, say, sticking with "established architectures" such as JDBC for client-server interaction ?

Another deliberate choice was that since I wanted to focus as much as possible on building the server, the logical consequence was that I should spend as little time as possible on making the client-side work, therefore "crude but effective" has always been the leading paradigm for client-side components development, systematically prevailing over "slick and neat". Especially for everything UI-related.

Another choice that more or less followed as a logical consequence, was to reduce dependencies on external packages to absolute zero. I did not want to be faced with managing package dependencies, or finding replacements for packages that ended up in the death row, or learning how to use package dependency managers, or learning the operation (and of course the inevitable quirks and bugs as well) of such packages. Nor do I want to spend a single second deciphering licensing terms regarding redistribution or any such thing (I am not a lawyer). Every second spent on any such matters is a second not spent on the server. So even the package with the facilities underpinning the web UI are Do-It-Myself. (Those who frown upon that may want to consider that the MS team behind Excel started off with developing their own C compiler because they did not want to depend on which bugs others had or hadn't put into their compilers, or so I have seen it claimed.)

This led to the modular division of the project that you can clearly see reflected in the [Home] page.

First versions

During its now +- ten years of development (not always at the same pace), six versions have been released. The publishing has always been done on the "Official Web Site", which can be navigated to using the tab of the same name above. Current release is 1.5. Release philosophy is "all-in-one" : the bundle always contains all the components for the version at hand. All components except the server are released including the source code.

Current situation

The projects and their pages are still here, the code no longer is. It's too old to still be relevant. Former ongoing work on 1.6 was discarded and a fresh start has been taken, using 1.5 as it was as a starting point.

Development philosophy

The following points apply :

1. Despite the effort to split the components more cleanly and have them defined here as "separate" subprojects, it can be anticipated that at least for some time to come, they will still not be developed entirely independent of each other. The whole package remains the whole package.
2. That is not taken as an excuse to disregard backward compatibility altogether. Removing existing public methods (or changing their signature) is not an operation I value very highly. Let alone do it too lightly myself.
3. The "zero dependence on external packages/libraries" (except java itself of course) is here to stay.
4. The server component is IP, closed-source, not to be found here on SourceForge, and is going to stay that way.