Thuban more modular?

[Bernhard Herzog]

Bernhard Reiter <bernhard at intevation.de> writes:

> Am 31. Mar 2005 um 09:03:24 schrieb Jonathan Coles:
>> what are people's thoughts on moving some of what is now
>> core-functionality into Extensions? 
>
>> in general, thuban should provide a very basic framework onto which all
>> the real functionality is added. the concept of a layer is part of that
>> framework, but specific implementations of that concept are extensions,
>> no?

Have you been reading "On Plug-ins and Extensible Architectures" :-) ?
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=286


> I have seen this approach to modularisation raised as idea quite a few times, 
> but often the implementation did not really lived up to the expectations.
> One reason is that it add more bureaucracy to the developers,
> like the checks which components are here yet.
> In this way it also prevent to make one interface great for the users, 
> because optimising a huge number of possible component combinations
> puts more burden on the interface design side.

Some of this is addressed in the article cited above:

    Extensible application architectures such as Eclipse offer many
    advantages, but one must be careful to avoid "plug-in hell."

> Our progress with Thuban currently is slow and we do have competition.
> So my tendency is to not put more into Extensions, because it is more work.
> Instead we should extent functionality and speed to get it to
> enlarge the number of users.

OTOH, we do have Extensions and a stated goal of Thuban.  Extensibility
is mentioned on the Thuban home page and on the concept page it says:

    We think that extending Thuban via Add-ons is a good alternative to
    directly adding features to Thuban. It allows you to add some
    specific elements you need for your work. It even is possible to
    create your own custom applications with all the features of Thuban
    without the need of forking the development and maintaining your own
    branch of Thuban.

While this is true in principle -- GREAT-ER is a good example for this
-- the extensibility is relatively limited.  Some things that you might
want to do are not yet easily possible, like adding a new source of
shapes as the ogr extension has shown.

Increasing the modularity and extensibility of Thuban doesn't mean that
we have to go and implement a generic plugin infrastructure like Eclipse
(see thr article mentioned above) instead improving Thuban in a more
direct fashion.  We can and should continue the process we started with
GREAT-ER, that is, add extensibility when and where it is needed.  That
won't take many resources.  In most cases it should more or less come
about as a side-effect of the refactoring needed anyway when adding a
new feature.

However, and this is an area where Thuban could improve IMO, the
infrastructure we are building with this process should also be used by
the standard components of Thuban.  That will help to ensure that the
way plugins interact with Thuban is generic enough and not geared too
much toward one particular implementation.  It will also improve the
architecture of Thuban by reducing the coupling between the components
and increasing the modularity.

  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/