The Vision of SiebenGeisslein

Goals

The goal of Siebengeisslein is to simplify developing applications that require persisting data. While many persistence solutions have been tried, none has yet produced a really seamless integration. While OODBs provide very lean and elegant solution for many problems, they fail in some important aspects: My vision of future software development is, that code and data are developed within a single environment. For example there is no code generated for the GUI components, but GUI components are instantiated, manipulated and then persisted. The persisted data is then installed along with the application. Also database tables are defined within the IDE. If the table is structurally modified (e.g. an index is added) and the new version of the application is installed the table of the already installed application will be updated to reflect these changes. When the application is updated, the new code-base is installed into the datastore and the data is merged with the existing data. Even currently running instances of the application are beeing updated. From a users point of view this will result in new features/bugfixes becoming available, but not in an interruption of his workflow. The state of the application (currently active form etc.) does not change.

How does it work?

Class Evolution

When classes are changed in Feder all changes are recorded. This way Feder "knows", if a field has been renamed, or if an old field has been removed and a new field has been added. Building on this knowledge during deployment a constructor is created, that can read and convert instances of every version of the class.

Merging Application Data

Data that is installed along with the application has to be updated when the application is updated. Because customizations might have been made, the application data has to be merged. All data that is installed along with the application therefore has to implement the Mergable interface.

User Scoped Variables

User local variables make it possible to reference user dependent objects from static content. For example, a ListBox might refer to different models depending on the currently active user. This way the whole structure of the GUI components can be kept static.

What is still missing

Currently all features only exist in rudimentary form. They only show the concepts, but cannot be used for any serious development.

The future

Do you want to help shape the future of SiebenGeisslein? Feel free to contact me !