[kforge-user] [0.14 enhancement] Trac configuration file

[John Bywater]

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:
http://project.knowledgeforge.net/kforge/trac/ticket/45

Then, I think I'll add that service attribute. Any suggestions for 
names....??

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?

Best wishes,

John.