Overview of the KForge System
+++++++++++++++++++++++++++++

     +----------------------+   +------------------------+
     |Command Line Interface|   |Kforge Web Interface KUI|
     +----------------------+   |     (Django Based)     |
               |                +------------------------+-
               |                        /
               |                       /
               |  +-------------+     /
               -->|Command Layer|<---/
                  +------+------+
                         |               +------------------+
                         V               |Event Notification|
            +------------+-----------+<--+------------------+
            |DOM (Domain Model) Layer|            A
            +------------------------+<------     |
                         A                   \    |
                         |                 +-------------+
                +-----------------+        |Plugin System|
                |Persistence Layer|        +-------------+
                +-----------------+
                         |
                         V
               +--------------------+
               |     Database       |
               |(SQLObject -> PGSQL)|
               +--------------------+

Domain Objects
**************

Python: kforge.dom

  Person
  Project
  Member (binding between person and project)
  AccessControl
    ProtectionObject
    Role
    Permission
  Plugin
    Service (an instance of a plugin for a particular project)

Plugin System
*************

Python: kforge.plugin.*

  * A major aim in developing the KForge core has been to support a good plugin system.
  * Plugins have access to all KForge APIs
  * They also are notified of events by the DOM's event notification system
  * All KForge services will be provided as plugins.
  * All KForge tools will be provided as plugins.

WARNING: the term 'Service' has a double use to denote all the facilities provided to a normal user of the kforge system such as subversion, wiki etc. Note that some Services (i.e. instances of plugins) are not 'services' in that they may do other things for the system such as, e.g., logging or automotaic pdf generation.


User and Admin Interfaces
*************************

The System has two top-level interfaces suitable for administration and user access:
  * Command line (bin)
  * Web user interface (KUI) (kforge.django)

Both of these work through the Command Layer which centralizes application logic. In the future we plan to other top-level interfaces such as a SOAP or XML-RPC web api.

KForge and GForge
*****************

Original work on KForge proceeded by improving GForge which is itself a fork of sourceforge. The current stable beta site at http://www.kforge.net/ is based on this code. The idea was that we use this working system while grafting on new parts and gradually replacing bits of GForge. Initially work would be on replacing or adding to the internals and developing the KForge domain model based on the GForge one. This would have the benefit of retaining GForge's (relatively) stable system and developed web interface. It would have the cost that we would have to distort new work to make it compatible with GForge and/or exert significant effort to patch the new and old together.

Initial work on the core of the domain model did patch into GForge extend it (hence the current kforge site) but as the domain progressed this route has not proved sustainable. Experience has shown that to have real advance it is necessary for to properly control the domain model and not be held back by the GForge DB design. Thus KForge has now started on its own development track. All of the original DOM work has obviously been re-used and a replacement user interface is nearly at alpha stage. More info on the current system will be included in subsequent emails.i

