Comments on: Plug-ins: isn’t there a better way? http://www.protocolostomy.com/2008/06/25/plug-ins-isnt-there-a-better-way/ Made with only the finest 1's and 0's Thu, 26 Jan 2012 21:20:45 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Marc Laporte http://www.protocolostomy.com/2008/06/25/plug-ins-isnt-there-a-better-way/comment-page-1/#comment-6589 Marc Laporte Sun, 21 Dec 2008 00:16:19 +0000 http://www.protocolostomy.com/?p=326#comment-6589 Hi! I feel your pain. A better way? I think so, and it's called TikiWiki CMS/Groupware. People need/want features. Either you let everyone add them in the core or you have an API and hundreds/thousands of external modules/extensions/plugins. The problems are well explained above (dependency hell, code/feature duplication, etc.). TikiWiki has an all-in-one approach to features. Think of it as a suite of applications like Open Office. Tiki has more built-in features than any other Web app (if you know of one, please let me know). The features are built-in and all optional instead of offered via 3rd party modules/extensions/plugins, and getting write access to the code is very easy. Some people are concerned about all the features and that "it can't work" or "it's not the way to do it". Since Tiki has a different model than the "conventional wisdom", I feel it's important to explain how it works and why it works. I like to think of it as applying the Wiki Way to Software development. About explaining if it works, well the proof is there! Not to say that the all-in-core model is perfect. While it solves many issues, it brings another set of problems. One of which is having an admin panel with several hundred settings. But for us, it's a lesser evil. And we develop strategies to address these. Interestingly, even if the application is huge (over a million lines of code), it feels pretty nimble because it's a single code base and we don't have to worry about potential consequences to 3rd party code. If we need to re-factor, we just go ahead. Please read more here: http://marclaporte.com/TikiSucks Best regards, M ;-) Hi!

I feel your pain. A better way? I think so, and it’s called TikiWiki CMS/Groupware.

People need/want features. Either you let everyone add them in the core or you have an API and hundreds/thousands of external modules/extensions/plugins. The problems are well explained above (dependency hell, code/feature duplication, etc.).

TikiWiki has an all-in-one approach to features. Think of it as a suite of applications like Open Office. Tiki has more built-in features than any other Web app (if you know of one, please let me know). The features are built-in and all optional instead of offered via 3rd party modules/extensions/plugins, and getting write access to the code is very easy. Some people are concerned about all the features and that “it can’t work” or “it’s not the way to do it”. Since Tiki has a different model than the “conventional wisdom”, I feel it’s important to explain how it works and why it works. I like to think of it as applying the Wiki Way to Software development. About explaining if it works, well the proof is there!

Not to say that the all-in-core model is perfect. While it solves many issues, it brings another set of problems. One of which is having an admin panel with several hundred settings. But for us, it’s a lesser evil. And we develop strategies to address these.

Interestingly, even if the application is huge (over a million lines of code), it feels pretty nimble because it’s a single code base and we don’t have to worry about potential consequences to 3rd party code. If we need to re-factor, we just go ahead.

Please read more here:
http://marclaporte.com/TikiSucks

Best regards,

M ;-)

]]> By: David Avraamides http://www.protocolostomy.com/2008/06/25/plug-ins-isnt-there-a-better-way/comment-page-1/#comment-1448 David Avraamides Fri, 27 Jun 2008 02:33:14 +0000 http://www.protocolostomy.com/?p=326#comment-1448 I think the problems you are talking about are more about the implementation of the plug-in feature in FF and WP. The plug-in concept, as others have pointed out, is pretty good: develop a clean, solid core of a system with the important functionality, and then add an API to extend that functionality. Think of the alternative like Word or Excel. These are apps that simply add more "core" functionality with each new release such that the applications are large, complex and confusing to learn and use. If more of those feature sets were released as optional plug-ins, then users could disable the things that they don't use, resulting in a lighter app with a simpler menu structure. I think the problems you are talking about are more about the implementation of the plug-in feature in FF and WP. The plug-in concept, as others have pointed out, is pretty good: develop a clean, solid core of a system with the important functionality, and then add an API to extend that functionality.

Think of the alternative like Word or Excel. These are apps that simply add more “core” functionality with each new release such that the applications are large, complex and confusing to learn and use. If more of those feature sets were released as optional plug-ins, then users could disable the things that they don’t use, resulting in a lighter app with a simpler menu structure.

]]> By: sunny beach http://www.protocolostomy.com/2008/06/25/plug-ins-isnt-there-a-better-way/comment-page-1/#comment-1447 sunny beach Thu, 26 Jun 2008 15:10:15 +0000 http://www.protocolostomy.com/?p=326#comment-1447 > And when you say “yep, I’m using plugins!” the reply from support is to disable them immediately and see if the trouble goes away. That’s a problem. No, that's a huge feature. The ability to immediately narrow down the issue you're having is a good thing. Without plugins, you would either not have the functionality you want, or it would be baked in. Since plugins are opt-in, having them even if they are faulty is strictly superior to not having the functionality you want. And it's not reasonable to think everything you want can be baked in, unless you want to get the overhead of all the plugins everyone else wants baked in. If all of the plugins were baked in, then when you called support with an issue they would STILL have you open your settings and disable the features you are using to narrow down the problem, but you would also have to open your settings and disable the hundreds of features you are NOT using. > And when you say “yep, I’m using plugins!” the reply from support is to disable them immediately and see if the trouble goes away. That’s a problem. No, that’s a huge feature. The ability to immediately narrow down the issue you’re having is a good thing. Without plugins, you would either not have the functionality you want, or it would be baked in. Since plugins are opt-in, having them even if they are faulty is strictly superior to not having the functionality you want. And it’s not reasonable to think everything you want can be baked in, unless you want to get the overhead of all the plugins everyone else wants baked in. If all of the plugins were baked in, then when you called support with an issue they would STILL have you open your settings and disable the features you are using to narrow down the problem, but you would also have to open your settings and disable the hundreds of features you are NOT using.

]]> By: nis http://www.protocolostomy.com/2008/06/25/plug-ins-isnt-there-a-better-way/comment-page-1/#comment-1446 nis Thu, 26 Jun 2008 14:57:03 +0000 http://www.protocolostomy.com/?p=326#comment-1446 No easy way around this one. This is what "enterprise software engineering" is all about. Fight until version 1 of product A talks to version 2 of product B and then don't touch it again. One of the reasons Python comes with "batteries included" is to avoid precisely this problem. The debian project and its repository which keeps groups of compatible packages together are the once that handle it the best in my opinion. Hundreds of packages in stable just work after a simple installation most of the time. No easy way around this one. This is what “enterprise software engineering” is all about. Fight until version 1 of product A talks to version 2 of product B and then don’t touch it again. One of the reasons Python comes with “batteries included” is to avoid precisely this problem. The debian project and its repository which keeps groups of compatible packages together are the once that handle it the best in my opinion. Hundreds of packages in stable just work after a simple installation most of the time.

]]> By: m0j0 http://www.protocolostomy.com/2008/06/25/plug-ins-isnt-there-a-better-way/comment-page-1/#comment-1445 m0j0 Thu, 26 Jun 2008 13:17:30 +0000 http://www.protocolostomy.com/?p=326#comment-1445 @Krys -- sometimes foregoing an upgrade means more than just doing without wanted features. Sometimes there are security releases that are essential. What then? Well, you wind up choosing to do without the plug-in functionality that breaks when you apply the security fix. This doesn't even touch on what happens when there's a flaw in the plug-in itself and it's been left to rot by the original developer(s). @Krys — sometimes foregoing an upgrade means more than just doing without wanted features. Sometimes there are security releases that are essential. What then? Well, you wind up choosing to do without the plug-in functionality that breaks when you apply the security fix. This doesn’t even touch on what happens when there’s a flaw in the plug-in itself and it’s been left to rot by the original developer(s).

]]>