Edgewall Software

Changes between Version 7 and Version 8 of TracPluggableModules


Ignore:
Timestamp:
Nov 22, 2004, 12:52:47 PM (18 years ago)
Author:
mithrandi
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • TracPluggableModules

    v7 v8  
    214214Trac, 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.
    215215
     216''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.''
     217
    216218I 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.
    217219
    218220If 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.
    219221
    220 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.
     222''What benefit is there to maintaining a high level of coupling between the core modules?''
     223
     224I'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.
     225
     226''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.''
     227
     228Developing 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.
    221229
    222230--JamesMoger