Howdy, First of all, see relevant discussions at: * http://trac.turbogears.org/ticket/1655 * http://trac.turbogears.org/ticket/2275
I personally see this as a terrific idea and in the long term envision a system with drop in plugin (eggs?) repository(s) or installed globally. I have become spoiled with Trac's architecture and ease of extending and wish this upon TG. At http://trac.turbogears.org/ticket/1655#comment:16 I made some light comments regarding approaches to existing patterns (and a system) of plugin architectures. I won't repeat what I typed there but basically I mentioned 4 approaches I am familiar with: * zope.interface - http://pypi.python.org/pypi/zope.interface/3.5.1 * entry points (minimal exposure, but it seems robust from that exposure) * ABC (abstract base classes) - http://docs.python.org/whatsnew/2.6.html#pep-3119-abstract-base-classes * Trac like (which is zope.interface like) approach - http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture Note that ABC is >= Python 2.6. Now some questions... What exactly are the reasons/goals for wanting to implement a component based approach? Is it important to add not just implement new features that are themselves implemented by other plugins? How important is it to be backwards compatable? Thanks, Jason *** I will be at PyCon 2009 including the Sprints, so that would be a perfect time to discuss this. Also, I am going to propose a BoF for plugin/component based architectures. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
