Difference between revisions of "Plugin architecture backwards"
Iron Perth (talk | contribs) |
Iron Perth (talk | contribs) |
||
| Line 6: | Line 6: | ||
In some open source projects, this is obviously a very successful approach as discussion just inspires more discussion and code inspires more code. And it's code that we want. | In some open source projects, this is obviously a very successful approach as discussion just inspires more discussion and code inspires more code. And it's code that we want. | ||
Unfortunately for our purposes, in those types of projects, interfaces change and code evolves rapidly. With a | Unfortunately for our purposes, in those types of projects, interfaces change and code evolves rapidly. With a plugin architecture where we have consumers, Plugin Developers, we do not want to be evolving in a way that forces them to refactor their code on a monthly basis to meet the latest contracts. | ||
It is a pain, to be sure, but getting it right the first time will rescue a whole generation of platform engineers from suffering the confusion of meeting legacy decisions made because we simply didn't know better. | It is a pain, to be sure, but getting it right the first time will rescue a whole generation of platform engineers from suffering the confusion of meeting legacy decisions made because we simply didn't know better. | ||
However, this doesn't mean we shouldn't be coding. There are a lot of prototypes and proof of concept programs that can be written so that we may advance our knowledge to a point that we can write a final plugin specification that is mostly complete and does not require constant change as we move forward. | However, this doesn't mean we shouldn't be coding. There are a lot of prototypes and proof of concept programs that can be written so that we may advance our knowledge to a point that we can write a final plugin specification that is mostly complete and does not require constant change as we move forward. | ||
Latest revision as of 21:15, 26 February 2007
Patching early and often, Backwards Compatibility, and Plugin Architectures
There has been some discussion regarding patching early and letting the code be the design.
In some open source projects, this is obviously a very successful approach as discussion just inspires more discussion and code inspires more code. And it's code that we want.
Unfortunately for our purposes, in those types of projects, interfaces change and code evolves rapidly. With a plugin architecture where we have consumers, Plugin Developers, we do not want to be evolving in a way that forces them to refactor their code on a monthly basis to meet the latest contracts.
It is a pain, to be sure, but getting it right the first time will rescue a whole generation of platform engineers from suffering the confusion of meeting legacy decisions made because we simply didn't know better.
However, this doesn't mean we shouldn't be coding. There are a lot of prototypes and proof of concept programs that can be written so that we may advance our knowledge to a point that we can write a final plugin specification that is mostly complete and does not require constant change as we move forward.