Roadmap and plugins
Matthijs
of Habari. Maybe it's hidden somewhere or there isn't one on purpose.
One thing I specifically am interested in is the use of plugins and
they are used by Habari.
Plugins are great, in that they allow a system to be easily extended
in many different ways. You can even write one yourself, if the
functionality is missing and you know how to.
However, plugins have one major drawback. They make a system brittle.
For the stability and security of the system you use, you are not only
dependent on the core system, but on all the plugins you use. That can
lead to many problems. A concrete example is development and
upgrading. Each time you upgrade the system, you have to hope the
plugins keeps working. Or there's a bug introduced. You have to hope
the development of those plugins is maintained. Often or sometimes,
that's not the case.
Or maybe the core of the system introduces some functionality that
interacts/interferes with that from a plugin you use. Now what?
These problems are not minor, in my opinion. If you use the blogging
software for something other then a personal blog about your favorite
pet, say on your corporate website or you use the system for clients'
sites, any bug can be a big problem.
So even though I think plugins are great, and I have often used them,
I try to do it the least I can. When a single system (Habari,
Wordpress or any other software package) has a problem, at least you
can be fairly certain it will be solved quickly. However, if you
depend on many independent parts, you cannot.
So, what are your thoughts on this?
1) What is the roadmap and what are the functionality goals of Habari?
(in other words, what will go in the core and what in plugins)
2) What is being done to prevent problems like the ones I describe?
Scott Merrill
> (in other words, what will go in the core and what in plugins)
When we set out to create Habari, one of the things I was adamant
about was a documented roadmap, so that users would know what was
coming. We've been pretty lax about maintaining such a document, but
you can get a glimpse of some of our development priorities by looking
at the individual release goals:
http://wiki.habariproject.org/en/Releases/
For example, here's what we want to accomplish for the next (0.5)
release of Habari:
http://wiki.habariproject.org/en/Releases/0.5/Roadmap
> However, plugins have one major drawback. They make a system brittle.
> For the stability and security of the system you use, you are not only
> dependent on the core system, but on all the plugins you use. That can
> lead to many problems. A concrete example is development and
> upgrading. Each time you upgrade the system, you have to hope the
> plugins keeps working. Or there's a bug introduced. You have to hope
> the development of those plugins is maintained. Often or sometimes,
> that's not the case.
> Or maybe the core of the system introduces some functionality that
> interacts/interferes with that from a plugin you use. Now what?
One of the nice things about Habari is that we use object oriented
programming. This allows us to expose a specific set of API methods
to plugins that are unlikely to change. We can change the internal
functioning of those API methods without breaking plugins in many
cases.
Be advised, however, that Habari is still very young in its
development cycle, so things are _expected_ to break now and again.
As Habari matures, and we get a better understanding of what is
expected / required by the core software, the frequency and degree of
breakage should diminish a lot.
So far, almost all of the plugins created for previous versions of
Habari continue to work. Newer versions of Habari introduce new
methods and ways to do things, but rarely prevent a previously working
plugin from executing correctly.
Cheers,
Scott
Matthijs
roadmap would be a good thing. Not only for users, but maybe even more
so for developers.
> One of the nice things about Habari is that we use object oriented
> programming. This allows us to expose a specific set of API methods
> to plugins that are unlikely to change. We can change the internal
> functioning of those API methods without breaking plugins in many
> cases.
and hard about the (final) API when reaching a 1.0 release.
> Be advised, however, that Habari is still very young in its
> development cycle, so things are _expected_ to break now and again.
> As Habari matures, and we get a better understanding of what is
> expected / required by the core software, the frequency and degree of
> breakage should diminish a lot.
I just want to know more about this, as it's quite an essential part
of the whole development approach. Haven't read all threads back to
the beginning, so don't know the reasoning behind the current
philosophy. Maybe an idea would be to make a distinction between
supported plugins and third-party plugins. Meaning that independent
developers can develop plugins, but when these are good and important
enough they get included as some sort of core extensions. The
independent developers remains responsible for the development (and
gets all credits!), but:
- the plugin is tested by the core dev team as well, certainly when
new releases of Habari come out. If the API works well this shouldn't
take much time.
- in case there's a plugin, and the original developer isn't working
on the plugin anymore, the core dev team could take it's
responsibility and do the work itself. Or makes sure someone does it.
That way, you have a much more solid system in place. People can use
plugins/extensions and know they can at least be reasonably certain
that they are stable and safe to use. And will being "supported". If
you look at Wordpress, it's a total mess, in my opinion. There are
literally thousands of plugins, all nice and well, but half of them
have no development, you don't know anything about the security of
using them, etc etc. It has improved a bit with the lists of WP-
[version]-prove and non-prove plugins, but still.
You guys are on the right track with Habari, and I'll help in any way
I can. It's for this reason that I want to bring forward this issue.
Scott Merrill
> Had not seen those roadmaps. Indeed, a more formal and complete
> roadmap would be a good thing. Not only for users, but maybe even more
> so for developers.
There is some debate as to the value of roadmaps. Some feel that they
arbitrarily lock us into development goals which might prove
unworkable, or unreachable in the specified time frame.
This is an issue that we're still discussing. Your participation in
the conversation is valuable, and can help us improve our process.
> I just want to know more about this, as it's quite an essential part
> of the whole development approach. Haven't read all threads back to
> the beginning, so don't know the reasoning behind the current
> philosophy. Maybe an idea would be to make a distinction between
> supported plugins and third-party plugins. Meaning that independent
> developers can develop plugins, but when these are good and important
> enough they get included as some sort of core extensions. The
> independent developers remains responsible for the development (and
> gets all credits!), but:
> - the plugin is tested by the core dev team as well, certainly when
> new releases of Habari come out. If the API works well this shouldn't
> take much time.
> - in case there's a plugin, and the original developer isn't working
> on the plugin anymore, the core dev team could take it's
> responsibility and do the work itself. Or makes sure someone does it.
Habari has some of this already, though it's not well documented, and
the long-term ramifications have yet to be ironed out.
Anyone can create and release a Habari plugin. Anyone doing so is
obviously responsible for keeping up with Habari development, to
ensure long-term compatibility.
We have in place a "Habari Extras" repository for community-supported
plugins and themes:
http://trac.habariproject.org/habari-extras/
These items are given by their authors to the community, and everyone
with commit access to the -extras repository can make changes to any
plugins or themes stored therein. This provides several useful
benefits:
* it increases the number of people willing and able to make
improvements to plugins and themes, reducing bitrot
* it allows bugs to be fixed faster, as folks in more timezones can
respond to issues
* it provides a casual, comfortable "proving grounds" from which the
core Habari committers can evaluate folks for inclusion into that core
group
Several plugins have already been identified as "core plugins", which
means they get shipped with Habari. These are maintained by the core
Habari committers. I expect the number of core plugins will increase
over time, but we currently have no formal guidelines for deciding
what plugins are or are not included.
Similarly, we don't have a formal guideline yet for how plugins and
themes get added to the -extras repository. Right now, it's pretty
relaxed and we allow folks access more often than not. Over time, we
hope to formalize this in some way.
> You guys are on the right track with Habari, and I'll help in any way
> I can. It's for this reason that I want to bring forward this issue.
Thanks! We're glad that you're willing to be involved. We look
forward to your participation!
Cheers,
Scott
Matthijs
> There is some debate as to the value of roadmaps. Some feel that they
> arbitrarily lock us into development goals which might prove
> unworkable, or unreachable in the specified time frame.
programming, not having a too formal process, not being tied to
unreachable deadlines or features-not-really-needed-anymore, etc. At
the same time, I can imagine that there is a set of features for a
blogging engine that are expected to be included at some time. Setting
at least some goals also might help to focus a bit. At least for me
when I work on projects ;)
> Habari has some of this already, though it's not well documented, and
> the long-term ramifications have yet to be ironed out.
> Similarly, we don't have a formal guideline yet for how plugins and
> themes get added to the -extras repository. Right now, it's pretty
> relaxed and we allow folks access more often than not. Over time, we
> hope to formalize this in some way.
> Thanks! We're glad that you're willing to be involved. We look
> forward to your participation!
place feels good, something I was missing with another blogging
platform (you know which..)
Cheers.
Arthus Erea
> and hard about the (final) API when reaching a 1.0 release.
features are added to the core. Of course, any API updates should be
rigorously tested to not cause breakage: however, there should never
be a "final" API. As a plugin developer, I am in charge of keeping up
with the times and will be very interested to see new methods and
interfaces added to the system. Saying that, I don't want my old
plugins to break. Essentially: keep all filters/actions doing the same
thing (but feel free to change the internals), but continually add new
ones to interact with and reflect the changed and more sophisticated
Habari,
Matthijs
> features are added to the core. Of course, any API updates should be
> rigorously tested to not cause breakage: however, there should never
> be a "final" API. As a plugin developer, I am in charge of keeping up
> with the times and will be very interested to see new methods and
> interfaces added to the system. Saying that, I don't want my old
> plugins to break. Essentially: keep all filters/actions doing the same
> thing (but feel free to change the internals), but continually add new
> ones to interact with and reflect the changed and more sophisticated
> Habari,
plugins being developed, any change will guarantee breakage somewhere.
That's why its wise to think long and hard about the API you're going
to have. As Scott mentioned, if you have a good, limited API you can
change anything inside without breaking the external interface.
Arthus Erea
> plugins being developed, any change will guarantee breakage somewhere.
> That's why its wise to think long and hard about the API you're going
> to have. As Scott mentioned, if you have a good, limited API you can
> change anything inside without breaking the external interface.
return same value)... while continuing to add additional actions and
filters. Adding new calls does not mean old calls will be broken.
Ali B.
Having said that, API changes are only possible to major releases. It is understandable that as a pluging developer you'd not want to see your plugin breaks in newer versions, but then again, you should keep updating your plugin to comply with the new changes in the API should you need to. That way you make use of the new benefits and sometimes will be able to add new features as you discover new additions in the new API that may facilitate that. Needless to say, the plugin (and any software) users are always encouraged to update to the latest released version of your plugin.
By making existing API calls stay the same (accept same value and
return same value)... while continuing to add additional actions and
filters. Adding new calls does not mean old calls will be broken.
Ali B / dmondark
http://www.awhitebox.com
Arthus Erea
On Apr 12, 7:44 pm, "Ali B." <dmond...@gmail.com> wrote:
> If you keep adding stuff and not clearning the ones outdated, you will end
> up with a cluttered code and will not be easy to read and understand by the
> time habari hits 2.0 for example.
> Having said that, API changes are only possible to major releases. It is
> understandable that as a pluging developer you'd not want to see your plugin
> breaks in newer versions, but then again, you should keep updating your
> plugin to comply with the new changes in the API should you need to. That
> way you make use of the new benefits and sometimes will be able to add new
> features as you discover new additions in the new API that may facilitate
> that. Needless to say, the plugin (and any software) users are always
> encouraged to update to the latest released version of your plugin.
up to date with the latest Habari code... especially if we get the
plugin repository and updating system working (so updates can easily
be pushed out to all users)
I think the API *should* continually evolve, but changes should be
restricted to major releases. We should certainly never reach a point
where the API is completely stagnant (no new features or changes being
added).
Matthijs
> I agree... it is a reasonable expectation that plugin developers keep
> up to date with the latest Habari code... especially if we get the
> plugin repository and updating system working (so updates can easily
> be pushed out to all users)
developers keep up to date. That is exactly the problem and the reason
of my concern.
> I think the API *should* continually evolve, but changes should be
> restricted to major releases. We should certainly never reach a point
> where the API is completely stagnant (no new features or changes being
> added).
the API which is used by plugins on one side and features or changes
in Habari itself. That can be done in several ways.
- have a solid object oriented code base with a good interface allows
you to change everything under the hood without changing or "breaking"
anything in the interface
- having a limited set of API interface elements. Enough to be able to
have lots of creative plugins, but limited enough to avoid tight
coupling.
- make sure the API or 'hooks' are made in such a way that the chances
of breakage are almost null. Say most plugins will do something with
the way output is handled. Then have some sort of post_filter() hook
which allows a plugin to do that. But in a limited, controlled way.