[kforge-dev] Taking stock of our current development strategy

Mon Oct 16 14:55:02 UTC 2006

Dear All,

Recently I've been thinking hard about the relationship of 
domainmodel/kforge/ckan to the existing python webapp frameworks. We 
started work on KForge (and its core which has now become domainmodel) 
in April 2005 several months before either django or turbogears had even 
appeared on the scene let alone got close to 1.0. Other notable 
developments since we began work are the inclusion of (some) support for 
inheritance in sqlobject (v0.7) and the maturation of the wsgi effort 
(wsgiref is now part of python2.5).

Below are some rough thoughts on where we are and where we can go. Let 
me know what you think.

Regards,

Rufus

## The Current Situation and its Origins ##

We now have our own 'mini-framework' in the form of the dm (domainmodel) 
package which provides:

   0. Standard plumbing including:
      * system dictionary (+ config loading)
      * logging
      * some testing extras
      * exceptions
   1. persistence layer (using sqlobject)
   2. domain model (objects + registers)
      * as well as some very basic objects (NamedDomainObject, 
DatedDomainObject etc)
      * and some non-standard ones (e.g. Person, access control stuff)
   3. command layer (i'm still not sure what the prognosis for this is 
-- do we really need it?)
   4. common webapp code (including an admin interface)
      * we do use django (in a very old version) to:
        * provide a web server
        * do url mapping,
        * do templating
        * help out with our manipulators
   5. A plugin system with a limited form of event handling and notification

The key question is how much of what we have done is specific to our 
projects and how much we could get from using an external framework.

## The Options ##

1. Stay as we are in the main

   * If we do I suggest replacing some parts of django (e.g. templating)
   * might be able to increase reuse in certain areas by using e.g. wsgi 
more heavily
   * could we pare back our domain model to be closer to sqlobject (or 
if not articulate clearly what we are gaining from having our own domain 
model base objects)

2. Move fully to turbogears or django or ...

There are large benefits to using as much of a framework such as tg or 
django as possible in terms of sharing in the combined work of many 
other hands (and in contributing to that).

The question is to what extent can we do so? To really get much more 
integration we need to be able to plug more directly into the domain 
model. The big question then is whether we can do inheritance.

Furthermore while e.g. turbogears provides some kind of access control 
model it is not clear how suitable it is to our situation (e.g. to 
kforge). It might well turn out that adapting tg to our purposes would 
actually entail more work that it has taken to get our system working in 
the first place.