Sean Coates wrote: > > The example in the wiki (http://wiki.habariproject.org/en/pluggable#provides) > is: > <provides> > <feature > url="http://wiki.habariproject.org/en/feature/podcast";>podcast</feature> > </provides> > Does this mean that the "podcast" hooks can never change? What if we have > "podcast2"? I guess I just don't understand.
My original idea for this was to use hook/API function signatures for compatibility. So rather than having a single feature identifier to represent a number of things, you'd add a bunch of hashes for the entrypoints your plugin used within Habari. Explaining how this worked seemed problematic. So, it seemed better to have a convention that allowed plugin authors to say that they implement something in a certain way, and characterize that method with a single, descriptive, *documented* feature identifier. These features are somewhat analogous to OOP's Interface idea. If someone implemented podcasting in a completely different way, offering a different set of functions, then they'd probably need "podcast2". Or they could supplement the existing "podcast" feature with the names of the features they add, like "podcast video". Truly, "podcast" is a very abstract feature. More documentation should be done on how these things would best work, he says as he returns to watching TV. > > You seem to agree. What's your opinion on how to do this? There needs to be something that marks an in-development version of a plugin as such, and it needs to be automated. The thing I described before would do it. Two parts: 1) Make our /dist/plugins build script insert "-dev" on the plugin info for packages it builds from branches. 2) Add code to Habari core to detect .svn stash files for branch plugins, and display "-dev" in the plugin listing for those plugins. I think developers would be willing to apply the necessary tags manually by social convention, but the sheer effort would be anathema to it happening in reality. So if we make it easier by doing the above things (which seem comparatively simple and able to implement once) then we all win. Owen -- To post to this group, send email to habari-dev@googlegroups.com To unsubscribe from this group, send email to habari-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/habari-dev
