Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-dev] What's happening after 2.1?

Dave, I am glad to see this kind of proposals being put forward.
I've had some similar thoughts when I first started working on the Eclipse
help system, and also wanted to see a more pervasive way of writing eclipse
views/wizards/etc. using a web browser widget (these days, most developers
are more familiar with writing web based interfaces then desktop based).
We worked around the custom protocol handler for implementing "live help"
(calling workbench functions from help pages) by running a servlet in the
embedded tomcat plugin, and interpret the parameters in the url
accordingly.
 Unless the browser is shipped with Eclipse, I think the protocol handler
would have to be registered uniquely on a machine, and it would be hard to
differentiate between multiple eclipse instances running at the same time.
One can get by without having to register a protocol handler on the system,
and just use http calls to the eclipse tomcat plugin. As long as all the
links are navigated from pages loaded from a local eclipse webapp, or the
local tomcat address is passed to pages loaded from the web, all the http
calls could be intercepted by a servlet running in eclipse and processed
accordingly (perhaps using URLStreamHandler's registered using the provided
eclipse extension point).

-Dorian


|---------+----------------------------->
|         |           Dave Orme         |
|         |           <DaveO@ASC-iSeries|
|         |           .com>             |
|         |           Sent by:          |
|         |           eclipse-dev-admin@|
|         |           eclipse.org       |
|         |                             |
|         |                             |
|         |           04/23/2003 12:12  |
|         |           PM                |
|         |           Please respond to |
|         |           eclipse-dev       |
|         |                             |
|---------+----------------------------->
  >-------------------------------------------------------------------------------------------------------------|
  |                                                                                                             |
  |       To:       "'eclipse-dev@xxxxxxxxxxx'" <eclipse-dev@xxxxxxxxxxx>                                       |
  |       cc:                                                                                                   |
  |       Subject:  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








Back to the top