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."
At least this is the user's choice.
Bloat then becomes a consequence of the user's choices and not something forced upon the user by the developer.
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
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!
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.
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...
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
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
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
Does that make it a poor argument?
You can never go home again... but I guess you can shop there.
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)
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.
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/
Adding0 0,suspend=n
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=80
to the java command when you run the app you want to debug allows Eclipse (& others) to attach on port 8000 (of course you can choose any unused port number)
If you want to debug an applet while it's running in a browser, you can specify the same arguments in the applet control panel.