[kforge-user] all plugins are equal but some are more equal than others?

Sat Feb 23 18:51:53 UTC 2008

Rufus Pollock wrote:
> Martin Fuzzey wrote:
>   
>> Hi,
>>
>> I see that kforge-admin db init automatically creates an instance of the 
>> trac,svn and mailman plugins.
>> Is there any particular reason for this?
>>     
>
> No and they shouldn't be created by default. As you say these should be 
> options. John and I have discussed this for a while but as most people 
> seemed to want these in 'by default' they were left in there.
>   

Rufus, are you suggesting that most people want something for which 
there isn't a particular reason? :-)

Let's close this discussion, and move on. As long, as the installation 
documentation and the test fixtures are changed to reflect the new 
initial state of the system, I don't mind.

But just before we do move on, I submit that the correct answer to 
Martin's question is yes, which follows from considering the original 
purpose of KForge, which was to be a well-factored Python replacement 
for the GForge system, to be used initially for the knowledgeforge.net 
service, and also to be available as a product for others to use similarly.

That is to say, the original purpose of KForge was not to a general web 
application plugin platform, delivered as blank platform from which 
people could do any number of webish things. In other words, the plugin 
design pattern was applied to KForge to separate the concern of making 
use of third party software applications to provide GForge-ish features 
(such as Trac, Subversion, Mailman) from the rest of the system.

In particular, when I designed the KForge core, I didn't want to make it 
dependent on any third party application. After this, of course it was 
very easy to add new applications. A few were added; more could be. (By 
the way, we also created some non-service plugins, to support access 
control, web service configuration, email notification, etc. That why 
the method is called createServicePlugins() not just createPlugins(), 
and why removing it doesn't break the system. ;-) )

At this point, a discussion was started about shipping KForge without 
any plugins installed. Whilst I have no real objection to doing this, it 
does remain necessary to maintain the integrity of the conception of the 
system. I think, "so long as we ship KForge as one single Python 
package, it should do GForge things after installation." So, "plugins 
are installed."

But, as it is clearly much better to package the KForge plugins 
individually, and therefore to package an empty KForge core, and 
probably confusing to have the unpackaged system differ from this, how 
shall we present this blank canvas to the KForge user? Would it be 
adequate to have an extra line in the INSTALL file and a section in the 
KForge Guide? As the first thing a KForge user would need to do is 
create plugins, it would be considerate of the KForge developers to make 
this obvious to the KForge user in as many ways as possible. Could we 
pay some attention to this? I hate systems that semi-install, don't 
really work, and you can't find out why. I don't want to do this to 
anybody. :-)

Also, I would welcome the move to providing KForge as more of a 
framework. The design is object-oriented enough to support inheriting 
and extending KForge, just as KForge does Domain Model. I'm thinking 
about making an application of KForge called Develop. Then we wouldn't 
need to argue about things like captchas either. :-)

>> I would prefer to have debs for each plugin and when creating kforge 
>> instances only create those installed.
>> To do this I've patched the InitialiseDomainModel constructor to not 
>> call createServicePlugins() and it seems to work ok (I have a rather 
>> useless kforge with no services).
>> Is this ok or will it cause problems somewhere?
>>     
>
> No this is fine and won't cause problems.
>   

I agree, it just means KForge is initially safe and useless. :-)

Bye for now,

John.