| RE: [eclipse-dev] What's happening after 2.1? |
John Wiegand and I have been corresponding some about this subject. Yesterday, in an email to him I expressed excitement about the possibilities of developing Eclipse in the rich client interface direction. If done right, we have the opportunity to make Eclipse plug-ins optionally function as extensions to the World Wide Web.
Here's what I wrote:
Suppose we:
- Create a cross-platform SWT web browser component (most likely using Mozilla's Gecko engine).
- Create a web browser plug-in so people can do all their web browsing from within a web browsing view and/or perspective.
- Add a protocol handler to the web browsing engine for a new protocol. For purposes of this discussion, it could be of the form:
"eclipse://some.site.com/com.site.some.package.class/method?parm1=value1&parm2=value2"
This lets web applications load arbitrary plug-ins across the network and run specified well-defined methods within the plug-in. If the plug-in is already loaded, it just runs the plug-in's specified method. Parameters are handled by passing the method a request object containing a Map object with the parameters. (Note: I'm making an assumption here that this can be built on top of whatever component model Equinox comes up with.)
- Add Java security manager plumbing to handle plug-in sandboxing so we can safely load/run/unload anonymously-downloaded dynamic plug-ins.
- Finish the cryptographically-signed-plug-in stuff so the user can also permanently install Eclipse plug-in applications from trusted sources.
- Create a SWT hyperlink control that requests Eclipse to jump to some URL. If it's a HTTP or similar web browser protocol, then the web browser view in the current perspective is used. If it's an "eclipse://" protocol URL, then the platform will download and load the specified plug-in (if it's not already loaded) and invoke the specified plug-in method. If there is no web browser view open in the current perspective, one will automatically be opened.
This would allow Eclipse plug-ins to seamlessly exist as extensions to the current HTML-based World Wide Web infrastructure. The distinction between the Web and Eclipse just disappears from the user's point of view. The user can click HTML links to navigate to (or inside) rich-client Eclipse applications and he/she can click SWT hyperlinks links to navigate inside SWT applications and/or web pages. And of course, web pages can include Java applets that can communicate back with the host Eclipse platform using "eclipse://" protocol URLs.
Since there is already work to allow plug-ins to define and run JSPs from the embedded Tomcat engine, the server-side of these web applications could run anywhere--inside the Eclipse client itself or inside another server anywhere on the network. Or both (for n-tier apps).
Of course, while I'm at it I could also wish for an integrated email/news perspective and an IRC perspective and a word processor perspective and a spreadsheet perspective and a... You get the idea. But first things first. :-)
(As an aside: In my opinion, this is a good argument for relaxing the distinction between views and editors because I would anticipate that most of the time the web browser view would want to open itself inside the editor area of a perspective. Perhaps another way of looking at the distinction is to rename the editor area the "Main Content Pane". Then allow any view or editor to specify that it prefers to load itself in the main content pane.)
Best regards,
Dave Orme