On Jan 28, 11:42 am, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED] nomine.org> wrote: > -On [20080128 09:42], Christian Boos ([EMAIL PROTECTED]) wrote: > > >Noah Kantrowitz wrote: > >> Trac core is getting far too bloated already. Either we need to > >> seriously redefine what minimalist software is, or this won't end up > >> in core. > > >Perhaps we could redefine "bloat" as well. > > For what it is worth, I do not describe Trac's core currently as being > bloated.
This is not an easy discussion... Be it 'bloat' or 'minimalistic' in terms of features or code lines, I personally think there is one area of importance that sets Trac above the rest: The APIs, and the ever growing community that makes plugins and custom solutions with features that will never make it into Trac itself. Great credit to the component architecture for that, and no doubt we'll keep improving the number of ways to hook into Trac going forward. Trac has demanding users that are partly served by Trac itself, and partly served by the demanding developers writing plugins. To me (and hopefully everyone else) that is just a superb model. However, at least to me it is also becoming apparent that there are some things missing on the API-side moving forward. Working both on Trac and some large-ish plugins, the demands of 0.11 leads to quite a bit of not-so-nice code and plugin architecture. From the 'old' 0.9/0.10 times we have some shared core classes (like env, formatter, config etc.), the models for features that handles the db store and fetch, and various modules that provide the features (some sharing when reused between modules of course). The model (db) layer is generally not 'Trac aware' by todays standards - it has no conception of (or interest in) fine-grained permissions, notifications, manipulators, changelisteners or any such matters. We've added quite a few, but there will likely be a number of such features based on current roadmap. Current architecture says that if you want to make your own alternative interface to the wiki for instance (like this REST proposal, or current xmlrpc), all this needs to be redone in each of those plugins. Example: The xmlrpc plugin still has no sense of fine-grained permissions. None at all. The nice, lean 0.9-style layout of the xmlrpc testing a method call against a single permission must be redone. Much of that code is really nice and simple, essentially calling up the model object (like WikiPage), and calling its 'create' with arguments. Reading current code, it all looks deceptively simple. However, every single xmlrpc method now needs to check whatever resources it handles against permission policies. A wiki getAllPages() call from xmlrpc should return the same basic content as the TitleIndex macro if these two implemented the fetch and check in identical manner - making the same model calls, the same resource specifications, and the same permission calls. If it is a page update, it needs to make sure that any manipulators are called and handled correctly, and that listeners are notified about the modification afterwards. Why? I think the Trac 'developer layer' (no 'business' here :-) would be greatly enhanced by supporting an alternative RPC interface of sorts - in, or close to, core. That would (in theory at least) force the project to layer the code base properly. All the Trac-aware 'gets' and 'updates' out of the various web_ui files and into the shared, developer-friendly classes, methods and functions. Making the web interface code would be mostly templating and input/output checking and handling, rpc/rest much, much simpler. > > I agree with that sentiment Christian. I think we need to define the > boundaries a bit, especially given the roadmap and goals towards and for > 1.0. > I think so too - mostly as the project needs a shared sense of purpose. My vote is not +1 for 'bloat'. I firmly believe Trac should be minimalistic in terms of features - we should never consider being all things to all users. However, putting effort into the APIs and core services like the project has done - and should continue to do - will ensure their needs can get served building on Trac anyway. Speaking in terms of number and quality of developer interfaces, I think it will be a long time before they can be considered 'bloated'. That isn't where we should make our compromises. :::simon https://www.coderesort.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
