Changes between Version 7 and Version 8 of TracPluggableModules

Timestamp:

Nov 22, 2004, 12:52:47 PM (19 years ago)

Author:

mithrandi

Comment:

—

TracPluggableModules

@@ -214 +214 @@
 Trac, as defined in the logo at the top of this page, is an SCM Issue Tracker/Project Manager.  It makes good design sense to have a modular architecture (as it is now) and a plug-in interface for non-core extensions, but to make everything a plug-in??  What would Trac become?  It would be an empty shell that loads Python modules - but we already have Python to load Python modules.
 
+''Not an empty shell that loads Python modules, but a shell designed to contain SCM-related modules, combined with a collection of useful modules focused around project management.''
+
 I would say that the features available in Trac 0.8 are pretty close to what I would consider core functionality - but that is because I want the total package, one-stop shopping: SCM Issue Tracker/Project Management.  I can spare the 50 or 100k of disk space per module, even if I don't use them.
 
 If a user doesn't want to use the TracRoadmap or the TracBrowser, etc - then why not have some boolean settings in TracIni to disable their appearance?  Its a poor-man's way to eliminate "bloat", but it would keep the current "core" intact.
 
-I'm all for a plug-in interface for TracReleaselist and whatever anyone else can dream up (Anthill or CruiseControl plug-in, anyone?)  Personally, I do not think that refactoring the core into individual plug-ins provides any real benefit.  Developing a good plug-in extension interface for the existing core, however, would be very worthwhile.  And to develop a good interface is going to be tricky enough.
+''What benefit is there to maintaining a high level of coupling between the core modules?''
+
+I'm all for a plug-in interface for TracReleaselist and whatever anyone else can dream up (Anthill or CruiseControl plug-in, anyone?)  Personally, I do not think that refactoring the core into individual plug-ins provides any real benefit.
+
+''Refactoring the core would make it easier to abstract the frontend away from the backend, so that other frontends (an XML-RPC interface, say) can be constructed more easily.''
+
+Developing a good plug-in extension interface for the existing core, however, would be very worthwhile.  And to develop a good interface is going to be tricky enough.
 
 --JamesMoger