Last week I wrote a bit about the high level ideas that form the foundation of the next generation of Ilwis. Though the piece was a bit (very) general I still felt it was necessary to write that down as it is the starting point of everything else. The core design of the framework is connectivity and not functionality. The assumption is that once you can connect to anything, functionality (done by ‘others’) is easy to add.

So what scenarios are we thinking about? Basically this is summarized in the picture below

What we see here is not a single Ilwis anymore but many variants of Ilwis running in different contexts. We see the traditional Ilwis desktop (though there might be more Ilwis desktop clients), we see Ilwis running in a container of an application server , we see Ilwis running on mobile device(s) and inside a browser. I am not saying that I will realize all these scenarios, that would be a bit over ambitious. But, the framework should be able to cope with all these scenarios. And with cope I mean, it should be relatively straightforward to build it.

So the next step would be to mold the requirements we can learn from these scenarios into a coherent overview that we can use to build the Ilwis-Objects framework. After a number of discussions the picture that emerged was the following

And this is really the core of the design ( in a boiled down kind of way) of the next generation of Ilwis. The finer details and implications will come in later blog posts but I will try to sketch a general picture of the meaning of all these blocks.

The Core is formed by the center blocks of Kernel and Ilwis-Objects. This is the part of the framework ‘everybody’ will always use. Everything is programmed against the interfaces they expose (and thus following the KISS principles). The kernel basically is the traffic controller and resource manager. It determines who can do what and where all things can be found that Ilwis controls. The Ilwis-Objects ‘shell’ around the the Kernel defines the basic data classes and interfaces that Ilwis uses to access data/functionality. It defines for example, what is a rastermap and how do I access a table? What is a coordinate system, how are semantics of data defined and what is an operation?

Below the Core is the Connector part. This part abstracts data/operation access from the Core. The core doesn’t know what is the format of the data sources it accesses, it doesn’t care about the nature of the operations it uses. This all to ensure that the client layer ( the top) can work with data/operations in a transparent way.

The last part is the client layer. This uses the Core to realize the scenarios mentioned in the earlier picture.

The whole is organized in a very modular way. Apart from the Core, all other things in the system are plugins. So Ilwis clients, desktop or server side can be put together in anyway that fits your particular scenario.

At the moment there is a working version of the Kernel and Ilwis-Objects and two connectors. Not that it is finished ( I wish 🙂 ), but the core principles are in there.

Next week I will look at  the connectors. How they work and what you can expect of them.