Christian Boos kirjoitti: > [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. > > > Now some brainstorming about the simpler installation part :-)
Hopefully that storm didn't damaged anything further... :-) > 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). Setupflow described here follows pretty much something that many other web projects I've seen use. First you install bunch of stuff, then bootup initial (admin) environment, do standard settings and after that you create that first ready-to-use environment. That push it further that admin interface could contain means to create new environments so no commandline would needed. -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
