bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Tests and CI (was: A word on Release 2)
Date Thu, 11 Oct 2012 00:12:43 GMT
On 10/10/12 18:26, Peter Koželj wrote:
> I admit it, some of my fears could just be the cause of the fact that I am
> not familiar with Trac plugin architecture and the Trac plugin ecosystem as
> a whole yet.
> Just a few use cases for quick "does it float" test:
> 1. Let's say we adopt some plugins for multiproducts, ticket relations,
> data import/export and so on...
> 2. Then we want to add user (admin) defined ticket relation per product
> 3. And then we want to support custom ticket workflows per product and per
> ticket type
> 4. And now we want the ticket import/export from/to Jira to work across
> Trac and all other plugins (including ticket relations, multiproducts and
> custom per product workflows plugins)
> 5. Add white labeling across Trac and all other plugins
> 6. Implement new search query language that will understand tickets,
> products and relations
> 7. Add REST API's for all of the above
> 8. ...
> Now, all this plugins (products, relations, import, export, search, white
> labeling, new search...) will either have to know filthy little details
> about each other (complex inter-plugin dependency) or some super heavy
> shifting in the plugin interface will be necessary. And that super heavy
> shifting will have to be pushed back to Trac (if it wants it) and only then
> to these plugins or create new Bloodhound plugin API on top of Trac plugin
> API and then request plugin authors to support it.
> Am I missing something?

I am not sure that I see the same difficulties. It seems a pretty normal 
thing for a program to be divided into components in such a way that 
keeps filthy details hidden. All we are doing here is allowing the set 
of components to be distributed between core trac, bloodhound plugins 
and external plugins. This is achieved through Trac and plugins defining 
interfaces, with components then being able to implement the interfaces 
and/or iterate through components that provide the interface.

So far I have found little reason to put any "super heavy shifting" into 
trac itself as they appear to have provided enough interfaces to allow 
for some fairly complex subverting of standard trac processing. The 
namespacing for multiproducts is a case in point where, so far, it 
appears to be achievable outside of trac. If it is not possible to do 
all that we want to with, say, per-product configuration or workflow, it 
might be that we will need to introduce a new interface to Trac to allow 
us to take over processing at the appropriate time but I am hoping that 
this will not be necessary.


View raw message