Last week I wrote about the ‘why’ of a next generation Ilwis. This week I will talk a bit more about the foundation of the framework. We have a number of explicit goals we want to reach with.

1. Connectivity. The physical format or location of data is irrelevant. It is about the information contained in the data. So independence of format and location is a primary goal
2. Interoperability. Integration of different providers of functionality in a transparent way. Not limited to the access protocol they use.
3. Accessibility at programming level. Ilwis is and will be written in C++ which can be a technical challenging language. To ease the threshold for external programmers we will
   – Use an external C++ interface that is very simple to use for those who want/need to program in C++
   – Provide bindings to other languages. Python and Java are the primary candidate
   – Ease the threshold for desktop – UI programming
4. Flexibility. The framework must be deployable in multiple roles. From the traditional fat-desktop-client to lean mobile clients and client/server configurations. There will not be one Ilwis, but many (in different roles).

Now these are lofty goals with, but good intentions don’t make good software. So how realistic is it to have such an ambitious list of targets? That is a question of design. The point is that some of these goals are actually closely related. By solving one, you might have also have taken a big step in solving the other. So the trick is choosing a design that can serve multiple targets.

I am a huge proponent of the KISS principle, Keep It Simple Stupid. I firmly believe that nine times out of ten ,when people come up with complicated solutions, they haven’t really understood the problem. Odd as it sounds but it is much more difficult to make a sound but simple solution compared to a complicated one.  Simple solutions often sound obvious after they have been proposed but the process of finding, understanding and shaping the requirements of a seemingly complex problem can be quite laborious.

So what does do to our 4 points over ambitious and high minded scheme? Well actually a lot if you realize that they all revolve around finding a common representation for information. Sounds obvious, but that is all there is. If we have a suitable general model in which we can mold our data and our operations we solve point 1,2 and 4 and most likely have a good shot at 3.  So how do we come to this conclusion?

• point 1 is obvious. Map the external representation of data, to an internal one (which is the ‘common’ representation) and you have the connectivity. All data has the same interface. Note this works both ways.
• point 2 is also obvious when you think about it. If operations can be reduced to a single format this can be used as common representation throughout the framework. This is actually straightforward, any operation can be reduced to a textual representation with zero or more input parameters, a identifying name and zero or more output parameters. The only thing that needs to be done is translating parameters to a common format and registering the name of the operation so that the framework has a common reference to use the operation. Translating parameters is more or less the realm of point 1, and registering names is no rocket science. Again, note that this process must works both ways, external operation to internal one and vice versa.
• Point 4 becomes fairly trivial if we add the requirement that the framework must be properly modularized so that we can pick and choose which parts we want and which we don’t want for a certain role. As all parts have a common interface and can access their ‘backing’ parent data/processing, we can mix and match to our hearts content
• Point 3 is a bit a consequence of points 1,2 and 4. It is unlikely that point 1,2 and 4 can be adequately served if we have a complicated model. In later blog(s) I will go more in depth about the (programming) interface(s) of Ilwis-Objects but suffice to say that I could lift the core concepts of Ilwis3, simplify, polish and modernize them and make them serve points 1,2 and 4.

So those lofty goals, can they be done in a reasonable time knowing the above? Well actually yes. I implemented a model, called the connector model. This already does all the things needed for point one to four (on non-ui things). Sure many things are missing ( e.g. I do a Georef corners but not(yet) a Georef tiepoints) but that is more a question of extending a working model then needing to redesign something.

In a few weeks I will start the first iteration for the model of the UI. That will be an interesting process as I will use a very different technology and programming model (qml) compared to the previous incarnation of Ilwis.

Next week I will talk a bit more about the building blocks for the framework.