[kforge-user] [0.14 enhancement] Trac configuration file
john.bywater at appropriatesoftware.net
Thu Oct 11 15:04:57 BST 2007
Hi Gunnar, Nicolas,
Thanks for your comments about this......
Nicolas Steinmetz wrote:
> Gunnar Johansson a écrit :
>> Finally, I agree with Rufus in that this is not really a KForge related
>> issue, it has to do with Trac management.. But maybe some KForge admins
>> find these hints interesting.
> Honnestly I see kforge as a nice frontend to command line and I think
> that one of kforge's goal is to facilitate the project management.
> If some *basic* configuration files need to be edited through ssh or
> webdav, it means I have to give some access on my box (for ssh) that I
> do not want to. If also I'm forced to use the command line for basic
> options, then what's the value of kforge ? (sounds harsh sorry...).
:-) Rufus and I have had exactly this exchange (well, more or less)!
Just to be clear about names, there is a concern about service
administration, and within this concern there is also a concern about
service configuration, and within this concern there is a concern about
access control configuration. There is then the related concern of which
access controller is used when pages are viewed.
I think it's fair to say that Rufus appears to prefer handing off
configuration and access control to the services, so KForge just doesn't
do that. Whilst my preference was that this absolutely shouldn't happen
because there would be little value left in KForge, more recently I've
started to vacillate.....
To produce a decision, my first move would be to reverse the "hand-off
OR don't hand-off" to be "hand-off AND don't hand-off". There are two
concerns, and we don't need to believe they are opposed.
To support choosing whether or not to delegate service configuration and
access control to the service, I think we could add a boolean attribute.
Not sure what the best name would be for this attribute. But my analysis
indicates this concern is a property of the service. So we need an
attribute on the Service domain model objects. The service's Apache
config that KForge generates can reflect the value of this attribute,
such that the service can be pretty much standalone.
To support KForge configuration and access control of project services,
we need to do a little more work. Certainly, the range of versions that
require support broadens the concern, as does the closeness of the
coupling. It might be tricky, but I think we must do this too.
So, let's go carefully, and try to pick off the things that are most
useful and most obtainable first. For example, it would be fairly easy
to present the trac.ini file in a <textarea> for editing. Also we could
present all the trac-admin options in a form.
Anyway, I'm just going to fix this now:
Then, I think I'll add that service attribute. Any suggestions for
Then, I'll try to do the trac.ini file editing, and see what I can do to
present the trac-admin functionality within KForge.
How does this sound?
More information about the kforge-user