[kforge-dev] access control to trac plugin

John Bywater john.bywater at appropriatesoftwarefoundation.org
Mon Feb 13 12:15:33 UTC 2006

Just a general note to clarify the term "subsystem applications" in 
relation to other terms:

The kforge system has a number of plugins, some of which integrate (to 
some degree) third-party software system. Such third-party systems 
appear as plugged-in sub-systems within the kforge system.

Examples of such sub-systems are the trac system, and the svn system.

The clunky term "a sub-system application" is a general term for a trac 
project, or an svn repository. It is what you get when you "apply" a 
"sub-system" (i.e. make use of it). In this way, if you "apply" trac you 
get a trac project-environment. If you "apply" subversion you get an svn 

In short, this is motivated by the requirement to extend basic kforge 
project service objects, according to the plugged-in software system 
that is being used by that service object. An kforge svn service uses 
the svn plugin, and has an svn repository; a kforge trac service uses 
the trac plugin, and has a trac project-environment.

At the moment, such things are being called "sub-system applications".

Can this name be improved? :-)



Rufus Pollock wrote:

> In 0.9.0 (the version currently running on knowledgeforge.net and 
> test.kforge.net) all sign in to subsystem applications such as trac 
> and svn is done via Apache auth running off the KForge user db (via 
> modpython).

More information about the kforge-dev mailing list