Dan, On Feb 15, 2012, at 11:50 AM, Dan Wendlandt wrote:
… lots of stuff I agree with ... > One major reasons people probably want to get their plugins merged is > for visibility, so that when people see the set of plugins available, > their plugin is on the list. We can probably solve this visibility > problem more easily by just providing a public registry I think this is better solved with the public advertisement than including the code within Quantum itself. > One other issue, if we decided to go with a split, would be how we > handle code that needs to be shared among a set of plugins. To some > degree, this could be handled on an adhoc basis (creating yet more > repos), but it definitely adds to complexity. That code should be within Quantum. > I'd also want to think more about what this means for API extensions. > My goal is that while an API extension may be proposed by a particular > plugin first, if this extension is designed in a generic way, it would > be able to be leveraged by other plugins and (perhaps after some > additional tweaks), become part of the standard API. In your > thinking, would extensions live in the main code base, or with plugins > (or an option for both)? My first instinct would be to say 'both' but my worry is that someone would define an API that becomes the de facto standard once its moved into Quantum. If a new extension is needed it would be better discussed across the community with the hope that our API stays consistent, especially if this functionality is important enough to make the move from extensions to the API spec. Aaron -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
