Slashdot Mirror
On Plug-ins and Extensible Architectures
gManZboy writes "Developers who want a flexible, configurable, IDE have long preferred plug-in architectures such as Eclipse over what they might view as the bloated, monolithic alternatives. Ever wondered how it all works? Well, ACM Queue just posted an article by someone who has worked on Eclipse since its inception, Dorian Birsan. He gives a great explanation of the Eclipse architecture as well as a thorough analysis of things to watch out for when developing or working with pure plug-in architectures."
No
Is there a plug in for Eclipse to get middle mouse click pasting, so I can get some consistency when using it in Linux?
Is bloat really a problem with too many features or more to do with bad coding?
How long is it before someone has so many plugins installed they are back to square one for bloat? Any operating system runs well when you first start it up. Users run into bloat problems after they have installed weatherbug, messenger programs and all the other crap they must have.
Might I suggest a slight rewrite of the first sentence:
Developers who want a flexible, configurable, IDE have long preferred plug-in architectures such as Eclipse over what they might view as the alternatives that promote pedophilia and Satanism.
It just sounds more professional.
The whole plugin environment works a lot like cooking a large meal. Add in extra ingredients, or substituting one ingredient for another can create a whole new experience. You could even use the same 'plugins' for different 'bases' if you provided the functionality correctly... like having pork (Java) as the basis for your sauce or chicken (.Net).
But, it can be a tremendously dangerous[tt] if not done correctly, so you could almost make the analogy of baking instead of cooking. Only specific elements can be used or you could ruin the whole dish... could you relate bloated software that hardly runs with something like a ruined custard or creme brulee??
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
To all you pattern zealots out there, this is called Inversion of Control. Typical crappy pattern name. Service patterns are among the most common used. Why? Because they are well-named. Who the hell came up with Inversion of Control? Pointless terminology. Plug-In Architecture is far more descriptive, understandable. Although you pattern guys don't get to sound like snotty professors when you say it. It's far too...practical
Hey, I'm just your average shit and piss factory.
" Is bloat really a problem with too many features or more to do with bad coding?"
Define "bloat"? Bloat is much like "object-oriented", with definitions that no one can agree on.
Is a program that does all that you need, and no more "bloated"?
Is "bloat" even relevent in this day and age of Giga-Hertz processors, and Mega-Ram, and Tera-storage?
Most of you have probably experienced "DLL hell" at some point and will look with suspicion on something that has the potential of being a "plug-in hell."
I think we already passed the potential phase a long time ago. After a while you either give up installing the latest milestone or give up your added plugins.
Systems can never be too secure, and you need to pay particular attention to securing a system based on plug-ins. Since arbitrary plug-ins can be installed--for example, by downloading them from the Web--and are allowed unlimited access to the system they plug into, security in a plug-in environment must be carefully planned. On top of this, some plug-ins require support for executing custom install code during installation, so they can have control over some parts of their installation. To prevent software security accidents or failures, the plug-in framework must address the issues of downloading from third parties and controlling a plug-in's access to other code and data. Supporting digitally signed plug-ins or secure connections helps, but it still relies on trusting the download source or the plug-in provider.
I love Eclipse actually, it doesn't do everything that I want though, for example MS .NET studio allows attaching to an already running process and debug it but Eclipse does not. It maybe due to Java limitations and maybe this feature will appear sometime in the future, but maybe it is just not possible to do? I am not sure.
Now look at Hurd. Hurd is a plugin environment if I understand it correctly, but it is too low level, but I still wonder, will it be possible to use Hurd as not only OS level runtime but for high level apps?
Just a thought.
You can't handle the truth.
first key concept: late-binding.
second key concept: single-root.
summary: this article talks about a non-single-root late-binding architecture. there are, of course, other organizations: the quintessential single-root late-binding program, and the raft of non-late-binding programs.
thus ends our cs moment of the day. we now return you to your regularly scheduled inanity...
So your saying Julia Child was a programmer?
There's at least one good thing about plugins and the OSS development model. It makes it easier for people to participate. Same with scripting.
Plug-ins are implemented as the plug-ins plug-ins with plug-ins over plug-ins plug-ins plug-ins plug-ins plug-ins.
Furthermore, plug-ins plug-ins plug-ins so that plug-ins plug-ins.
Mine eyes glazeth over.
P.S. plug-ins
P.P.S I just like saying plug-ins. It's a funny word. Plug-ins. Hee!
That was meant to be funny, right? Because few things are as so monolithically all-encompassing as Eclipse.
I should reveal personal bias from the outset: I despite Eclise. Though it sits open in a window just next this one right now, I still loathe it with an utter passion.
I cannot get its editor to put tabs in realistic, predicable places. I don't want my coding environment to start looking like MS Word, underlining things as problems simply because I haven't finished typing thm yet or am concentrating on another part of the design. I had to immediately turn off most of the auto-typing features such as adding brackets or quotes, because I found it vastly distracting. There's a plug-in to search the preferences! My god, that makes it out of control.
I tried to use it at home the other day to import four existing source files and then generate a build.xml file for me. It never even worked out how to import the files with the right directory root, which given a pattern of src/org/eruvia//FileBelongingToPackage.java should have been src, not src/org/eruvia/appname.
Can't stand the thing.
Cheers,
Ian
"thus ends our cs moment of the day. we now return you to your regularly scheduled inanity..."
Oh man. That's like SO deep. Encore! Encore!
Programming is a lot like cooking - a delicate combination of science and art.
Going on means going far
Going far means returning
Grid Portal is another pure-plugin architecture. It is a single executable JAR file which runs on Windows, Mac, and Linux and can be started in either GUI or command-line (CLI) mode. It comes with a plugin manager which allows you to easily install, update, and remove plugins. Screenshots are there as well.
Dreamweaver is also a great framework for plugins. While the host application still offers some functionalities, they are related with the actual implementation of the plug-in architecture. You probably don't know - but Dreamweaver is now mostly built from plugins, and those are built with HTML and JavaScript almost exclusively. The HTML editor is not a plugin, but almost everything else is, and the options are unlimited.
:). When building dynamic sites, the designer and the programmer always clashed as they have different value systems (the designer dislike programming, the programmer don't care about design). So Dreamweaver was built as a layer between the programmer and the designer - helping the programmer work with the designer by writing plugins for the IDE that the designer will use to create complex things.
Not only this plugin architecture is powerful, but it's also platform independent - you can easily configure it to generate PHP/ASP or JSP code with the same plugin implementation and different platform files. Everything is XML, and a lot of regexps are used to detect code patterns and parameters that are presented in the visual interfaces. This plugin system is so powerful, that it allowed us to build a fully functional Dreamweaver PHP support layer (they only supported ASP and JSP back then), in just several months.
If you've read the Cooper book - The Inmates are Running the Asylum you will understand easily how plugins have appeared in Dreamweaver back in the Drumbeat 2000 times - as a layer between the IDE user (Betsy - an HTML designer) and the hardcore programmer (I forgot his name, but he was a he
That's what a lot of companies are doing now with great success. <shameless plug>We're doing it - http://www.interaktonline.com - with significant results - 10000 licenses sold and 500,000 downloads for the free extensions</shameless plug>, and there are also a lot of other companies doing it (you'll find more on the Macromedia Exchange - a place where people exchange free and commercial plugins)
Dreamweaver also avoids the plugin hell using a powerful packaging technique (they came with their own package format - MXP - that knows how to do "safe changes" to the IDE - like adding menu entries, code completion features, etc). Those changes are applies using the Extension Manger - a nice piece of software that knows how to "undo" IDE changes when uninstalling an extension.
Want to learn something from a working implementation? Learn how Macromedia did it and a lot of interesting lessons will be learnt.
Alexandru
You're right, it all ends up as crap...
So is this why my roomate (who can't even cook mac and cheese without screwing it up) has an internship at Microsoft?
Using the Slashdot posting plugin for eclipse.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
After all, to extend your food analogy - it really IS like cooking - if you don't have everything just right, it might be (barely) edible, but it will taste like shite.
The article speak of plug-ins managing plug-ins. and then goes on to this:
The days of the tight, quick, responsive IDE (simple recipe) manipulated by a proficient coder (chef) producing tight code (tasty, wholesome food) are dead, replaced by bloatware (junk food full of calories but empty of nutritional value). Don't just supersize me - supersize my code!Bad enough we have the Java reflection API - now we need to "discover" what we've got available in our IDE as well. How long before we shoot the chef (the coder) and replace him with a microwave? Because that's where this is going.I for one do NOT welcome our xml-configured beowolf clusterf$ck of plug-in library overlords. There's still a time and a place for "less is better." A lot be[tt]er.
Eclipse as an example of software that isn't bloated.
ROFL.
Seems that the plugin-based architecture of eclipse hasn't helped a bit with loading times. On my athlonxp 2100 with 768mb ram, it takes about 15 seconds to load, same as netbeans.
Netbeans also has very good html/xml syntax highlighting and completion. I hope Eclipse 3.1 plays catchup on this.
Open Source Java Web Forum with LDAP authentication
I tried Eclipse a while back - the first thing I do with any programming editor is of course to load a text file and try editing it.
So I try to open a random xml file on my hard disk, and, er...wait, hang on, you can't do that. You can only load a file if it's in your project (or view or solution or whatever word it is that Eclipse uses).
I researched a bit, and found some other people ranting about this, but the official line was you should add such files to your project if you want to edit them, it's the right thing to do, blah blah blah.
Call me stupid, but that kind of language lawyer prescriptive idiocy is what I try to avoid, so I went straight back to my bloated monolithic IDE that nevertheless let me load whatever the hell file I want.
I'm downloading the latest version now to see if it will let me execute a technological marvel such as loading a file I want to edit...we'll see.
(Although the last time I tried Eclipse it took me fecking ages to get a JVM set up that would even allow it to start up - "run anywhere", indeed...)
I find it amusing that the article even calls the plug-in manager the "kernel". It seems like the research into this field is basically working on some meta-OS rather than something that will provide real extensibility to a system. All it tells me is that OSs need better interface specifications to provide what folks are looking for and so write their own meta-OS.
"There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
unfortunately flashout, which displays the newly compiled SWF inside eclipse and logs the debug output seems to work only under windows. linux and osX users have to use their browser and a custom solution for the debug info.
i love my new workflow. it's so much better than having flash open in another window only to compile my classes.
Those of you who want to try out a fully featured IDE for .Net can try out SharpDevelop. This is GPL'ed and the project (including source code) can be found at ICSharpCode.
.Net programmer.
I had written a couple of plug-ins for #D, and it took me less that two days to understand the architecture. Parts of the application are hacks, mainly because it does not have an industry heavy weigth behind it, unlike Eclipse. The project runs on contributions.
SharpDevelop architecture includes pluggable language parsers, components, add-ins etc. I will definitely recommend this application to any
Life is just a conviction.
The developers of the GPLed C# IDE wrote some well-presented documentation that discusses in part their add-in architecture: "SODA - SharpDevelop Open Development Architecture Almost all mid to large size software projects have some sort of add-in architecture. An add-in is basically an extension to the functionality of the main application. The common way to introduce an add-in structure is to load libraries from a specific directory at runtime. (Author: Mike Krueger)"
Beta only seems to work for Google. Such a shame.
In Eclipse 3.0.1, I attached to and debugged a web app in a remote tomcat.
being an IBM shop we have seen many of our beloved (read:working) tools being phased out in favor of an Eclipse based solution.
So far the net result has been bloated and very slow loading applications. The minimum memory requirement is 512mb with 1gb being recommended on user groups.
After my experience with it at work I would not touch it at home. Not a single developer here uses Eclipse, they all prefer to use the older programs that are no longer supported or are being phased out.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
So, what type of code do people produce?
I just read a earlier a long string of bashes around java & Open Office and then this item about Eclipse.
...
Let me tell you this.
A furiously anti-java, C++ist, debianist friend of mine tried it and found it cool for his C++ development !
It is a living demonstration that all that religious wrath around java is a non-sens.
Compared to the usual "Java is slow, Swing stinks, it closed source for playmobile developers."
Eclipse is fast, GTK native, full open-source with a very well done plugin architecture
You even have a full GCJ port for the zealots :
http://klomp.org/mark/gij_eclipse/
Eclipse uses an underlying OSGi framework. Much like the one my company makes.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
You want new functionality, you write or download some elisp. you want the functionality included in editor, you load it in you .emacs file. very clever.
In that sense, cooking is a li[tt]le like an onion. On the inside, you have the apical meristem, the root core of the onion, which provides it with its link to the ground, allowing it to obtain liquids and other important fluids from the ground. Just as you might add ingredients to the pot, this pulls carbon and water and "cooks" it using a highly developed cell structure into something else. You, in this sense, are the apical meristem, and you are "making" the onion by turning raw ingredients and energy into, what's essentially, food. And, of course, the onion is covered in a thick skin, which you might see as the presentation layer of the meal you cook - you don't just slop cells onto a plate, it's important the texture of the food is represented by the physical appearance. Your cooking, of course, is similar to programming an IDE - you might say that you're taking tools like Java, object libraries, slivers of code from memory, and converting them into a full blown application, similar to how you build the cells of the onion and turn it into a full blown onion. The outer layer of the onion is the UI of your program, and an end user can essentially take the onion and use it in their own projects, extending it as necessary. They add seasoning, fry the onion in butter, etc, making it their own.
We need to see the end project as the meal. We can see it as the onion, and in one sense, creating a final product for a cook, it is, in that analogy, but in the other analogy, it's just an ingredient. We need to give people the meal, and make the best meal we can, and they can add salt and pepper if they need it. Let's not just give them onion seeds.
You are not alone. This is not normal. None of this is normal.
The other day I had to write a bunch of code with similar lines. Something like
I hopped over to my *scratch* buffer and typed in a short emacs lisp function (three lines of code, if that). I evaluated it, switched back to my code buffer, and added the lines by hitting a key sequence. The above lines were reduced to M-x attr RET phone RET M-x M-p RET fax RET M-x M-p RET email RET, etc. I could've even bound the attr call to a chorded key press or two.
Total time to look up the docs and write the code to extend emacs: about a minute.
Total time spent compiling code, loading a "plugin", restarting emacs: 0.
Total time spent dealing with "you forgot the static keyword on line 12": 0.
Total time spent fixing my code after upgrading emacs: 0.
This is a feature that's been around for decades. Decades! When extending your editor is this simple, you'll do it more frequently.
The article speaks of up to 10,000 plugins:
That's 100,000,000 possible interdependency conflicts in a 1-on-1 scenario. And 10,000 pieces of code that may or may not be present on any one system. Version problems. Missing/out-of-date problems. Dependency problems.Then there's the security problems. 10,000 links - and your chain is only as good as the weakest one.
With 10,000 components, you're pretty much guaranteed that SOMETHING is going to need to be updated every day, even if the average component has a lifetime of 30 years (ha - fat chance)...
More likely to be able to make a good meal by throwing together whatever isn't crawling around in the bottom of the fridge, than keeping that organized over long periods of time.
My guess - we're fascinated by complex systems. So much so that we don't even bother to try to find a more elegant solution. We want the fancy desser[tt]s, the calorie-filled eye candy, more than we want to "just get the job done". Getting the job done isn't as "exciting".
And COBRA is "Plugins" done remotely.
Sorry to everyone. I just thought that OSGi might be interesting for Free Software developers. It is a very nice way to implement plugins in Java. It is even not so difficult to implement in a GPL product, it's just a spec of delayed loading of jar files with special a manifest. It's cool, that's all. Didn't mean to troll or anything... :(
I've used Eclipse on a program that uses both Java and C++ through a JNI layer. The Java side was pretty good, though I had to get used to the keys. The C++ side needed some help though. It's obvious that whoever dreamed up Eclipse thought of it as a Java project IDE and anything else second. And yes, there is a C++ plugin, but that doesn't go nearly as far as the Java tools built into the program, such as refactoring.
Have I wondered how it works? No. Do I ever see myself caring? It's a GUI application. There are dozens of them, all of which decompose to lots of API calls to create windows and register handlers. Big deal.
The other thing, "monolithic, bloated IDEs"? What other monolithic, bloated IDEs? Somehow I get the feeling the writer could be eluding to Microsoft's Visual Studio since well, IDEs on *NIX-land have largely been non-existent. Or last least, not very popular. Despite my lack of affinity for Microsoft in various ways, their Visual Studio product has been polished for years and years, before anything similarly worthwhile existed in *NIX-land. Being an EMACS head I could care less frankly.
Perhaps they were referring to Netbeans but considering this is about the only other IDE outside of Eclipse in the *NIX world worth bothering with, the fact that the term "IDEs" was used (indicating plural) is just more of the same... self-aggrandizing platitudes.
Zzzz,
-M
component != plugin
Indeed, many plugins are usually grouped together into a single "feature" (which is really more like a component than a plugin is). And features tend to be fairly, if not completely independent (apart from base/core components).
Put another way, I've got thousands of debian packages installed on my computer. Debian packages are more interdependent than most eclipse features and plugins (except for the eclipse core). Every day, some are updated, at my request. Occaisionally, things break or stop working in a way I expect, but in general, things keep steadily moving forward. So having thousands and thousands of interdependent software packages/components being updated actually does end up working.
So you see, it's not as bad as you make it seem.
MRSH-Recording device, corned beef sandwich with kraut, seafaring bird, and the foamy top of a beverage.
I prefer using hard tabs and letting the IDE/editor use a specified tab-width (say, 4 spaces per tab character).
IIRC, both Vim and Eclipse support this kind of tab-handling, and it's served me well thus far. I'm rather curious: why the bias against hard tabs?
I can't stress enough how important security is!
When you have a late-bound, extensible environment it is so easy to mess with it. Plugins by their very nature are supposed to be powerful, with hooks into the system at very low levels. This makes it very easy for virus writers, malware authors and spyware developers to run their code with full priviledge.
But lets forget about Spyware and Virus for a moment. Lets say you have a plugin architecture for an application that does proprietary financial calculations for loan approval. You don't want someone to come along create a plugin and change those calulations.
I think about this all the time because I have been developing plugin frameworks for the past 7 or 8 years. I really don't want to limit the functionality of the plugins because in all honesty I want the plugins to be as powerful as they can be so they change the calulations. I know it sounds like I am contradicting myself but the truth is I am not. Creating a plugin architecture is not a decision that you should take lightly.
When deciding to create a plugin system you have to be sure that you can handle the complexity and the inherent insecurity that decision brings you.
#1 point with plugin systems. Plugins are all powerful.
Robert
Bet this
Typically, we want to manage things in a declarative sort of way, with a high waterline, and have the code fret about the annoying details.
Then, suddenly, things no worky-worky, or we need to improve time/space/features of the code. Now we want that waterline lower, exposing more of our iceberg, so we can do some imperative sorts of things with it.
While not a GUI, I've been recently living this iceberg metaphor in a MS environment. Consider:
Duplicating this code in C-shrap or C-pee-pee is a non-trivial undertaking.
As for Eclipse...I fell short of being thrilled back around 3.0.
Dare I say, as an emacsor to a viman, that the old "rivalry" between the two shall continue, long past the eventual demise of Java, XML, and the Next Bloated Idea (NBI) has come to roost.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I've been impressed with Kdevelop since the 3.x rewrite (Gideon).
It has a plugin architecture, is native, and even has a decent vi editor kpart via yzis.
And I believe the killer feature of Kdevelop is the ability to import autotools projects - which is basically everything in the open source world.
Eclipse (CDT/C++ plugin) doesn't have this ability yet.
The other night I imported KDElibs straight from cvs, it parsed everything out, I had my class browser with the entire kdelibs project there, changed some configure options, and built the whole thing within the IDE.
- plug-ins that manage other plug-ins
- plug-ins that have nothing to do with the UI
- UI plug-ins
Sure, your system has thousands of components, and once in a while something breaks after an update.But how about an app you've written that depends on ALL of those thousands of components (they've already deployed apps with greater than 1,000 plug-ins). The changes of your app breaking just got bigger, because of all the dependencies.
It's a disaster waiting to happen. Combine this with something like Metafor programming for non-programmers and we're in for a real shit-storm.
This is the way Drupal works, and why it is so powerful.
OK, having read what astroturfing means (thanks, google), OK, almost noone knows what osgi is, and those who know hate it. Fine. Sorry! Again, trolling was not my intention, read my other posts around slashdot. I am not even working at that company right now, I am like 7 countries north of it, studying graphics at HIN, making doom 2 levels and enjoying a 6 months non-paid vacation and am eagerly waiting for the white nights here north of the polar circle. So there. Have a nice day.
Every single app I use seems has a "plugin" architecture. Add a couple hooks to your program, it's plug-in. Use DLL imports from multiple DLL's, plug-in. Design a whole modularity architecture, it's still "plug in". Support external config files that change a few presets ... freakin "plug in".
... Maybe eclipse has a standard registration and callback architecture, maybe it's a message bus, maybe it's an agent blackboard system, maybe it's AOPAlliance-style interceptors. Who knows, it's just got freaking plug-ins.
Component, package, library, expansion, whatever
I'm not asking for precise architectural details, just something to differentiate it from the term used by every kiddie who slaps together a template engine in PHP.
I am no longer wasting my time with slashdot
The sciences of food and programming are not quite the same. Though I would hazard a guess that many good chefs do not understand the science of cooking, while on the other hand many programmers do not understand the art of coding.
Going on means going far
Going far means returning
Well, I guess it's the developer's own dumb fault for depending on all those thousands of components.
In practice, independent developers don't depend on many other independent developers, so neither do their components.
I leave the benefits of end-user programming to the HCI researchers.
MRSH-Recording device, corned beef sandwich with kraut, seafaring bird, and the foamy top of a beverage.
There is only one standard editor.
The Eclipse plugin model is a really nice one.
First, it is really generic : you are not constrained to a particular subset of an API, like the "old-school" Netscape plugin API for example. Some would argue its over-generic : it does not provide a pre-built organization of extension points and extension for you, so you have to adapt one for your own needs.
It is also a proven base layer for a community development platform. Read: Eclipse has shown that thousands of independent developers and vendors can cooperate on this ground without stepping on others toes.
Finally, the plugin descriptors are really close to the IoC/code injection pattern. All this leads to a great toolbox for building componentized systems.
This is what decided me to port it to Perl for use in my console project. So Perl hackers will be interested to hear about PXP (Perl eXtensions and Plugins), recently uploaded on CPAN : http://search.cpan.org/~dbarth/PXP-0.1.2/
This library implements most of the Eclipse model and configuration syntax. Of course, it does not force you to derive your components from a particular, "fragile", base class : the library can work without any object dependency between the framework runtime and your program.
I'm trying to improve the configuration of the extension components, so that it is more compatible with code injection and "standard" Perl init() sub-routines, ie, not tied to a particular XML parser. This way, you'll be able to compose _and_ configure a program with regular Perl objects.
PXP has been use successfully in IMC, my other web management console project : see http://imc.sourceforge.net/ for more details.
You can discuss PXP on the IMC mailing list for now.
A cynic might observe that had you been using a less powerful editor, you would have been forced to write something like (will contain bugs):
$entry = join("", map {cleanAttr("comp_$_",
$totCompany_list[$i][$_]} qw(phone fax email));
which would have been the right thing to write.
In Perl, you should almost never be writing repetitive code. Sadly, you sometimes have to write repetitive Java - eg defining a bean.
Xenu loves you!
Actually, I thought Eclipse itself was a pretty satanic example of bloat ;)