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.
Cheers,
Gary
