on Wed Feb 13 2008, Christian Boos <cboos-AT-neuf.fr> wrote:
> [EMAIL PROTECTED] wrote: >> I would like OpenID as a plugin, but distributed with the base system, >> and tested with the base system. Please see perl: it's easy to add >> things, but perl doesn't come "bare" -- it comes with a number of >> modules as part of the base distribution, but you have to ask for them. >> >> OpenID should be easy to configure, but it doesn't need to be the only >> answer. More and more "core" functions should use the plug in >> functionality, but be distributed with the base system. >> > > Yes, I think this topic will become an important one in the coming months. > > I very much agree with what you said above, I think that having a > modular system should enable us to provide a good range of optional > functionality out of the box, like numerous other successful projects > do. In my opinion, this will have many positive effects, like favor a > closer collaboration between plugin writers and core developers, ensure > a better homogeneity for a given release and also make way for a simpler > and more modular installation. Does this mean http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/3142 wasn't quite as roundly ignored as I had thought by those who matter? > Now some brainstorming about the simpler installation part :-) > > I imagine the following: right after having installed or upgraded a > new Trac environment, the last step of the installation would be to > access the environment (tracd can be used for that) and see a somewhat > enhanced plugin administration module (an installation module?), where > one could select the major subsystems, and then pick additional > features, configure them, etc. > > It could look something like: > > ---------------------- > Congratulations, you've installed Trac 0.12. > > Now you can enable specific sub-systems that correspond to your needs: > > |x| Wiki > |_| Bug Tracker (ticket system) > |_| Repository Browser > |_| Timeline > |_| Search > ---------------------- > > Once the major sub-systems are selected, further plugins will be proposed. > > There could also be some interaction between enabling the plugins and > modifying the plugin specific configuration settings. > > Example for the repository browser sub-system: > ---------------------- > |x| Repository Browser > |_| Browse Local Subversion Repositories > |_| Browse Remote Subversion Repositories [EXPERIMENTAL] > |_| Browse Mercurial Repositories > ---------------------- > Note that we would use the [EXPERIMENTAL] warning to make it clear that > the plugin works but has potentially some rough edges, a bit like the > Linux kernel does for its drivers (or used to do - it's been a while > since I compiled my last kernel...). > > Once you select one or more of the above plugins, they could also show > the configuration entries attached to them, or link to some more > specific admin panel. > > > Back to the specific case of the OpenID plugin, we could have something > like: > > ---------------------- > General > Authentication Systems > (o) Default HTTP authentication > ( ) Account Manager > ( ) Use OpenID > ---------------------- > (well, I don't know much about the account manager and openid, so I'm > not sure they're on the same level or even if openid depends on account > manager, but you get the idea). This looks really nice in principle. If it were MediaWiki, you'd get a friendly web interface for configuring such things. Something like that might work better; I don't know. -- Dave Abrahams Boost Consulting http://boost-consulting.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 -~----------~----~----~----~------~----~------~--~---
