[[Image:Ok_green.gif]] Integration of a web server for intercepting remote commands.

[[Image:Ok_green.gif]] Integration of a web server for intercepting remote commands.

−

* [http://elonen.iki.fi/code/nanohttpd/ NanoHTTPD] is currently being utilized for this purpose as it is a less complex alternative to using one of the OSGi Http Service implementations (org.eclipse.equinox.http.jetty or org.eclipse.equinox.http). See the [[#Secondary Goals | Secondary Goals]].

+

* [http://elonen.iki.fi/code/nanohttpd/ NanoHTTPD] is currently being utilized for this purpose as it is a less complex alternative to using one of the OSGi Http Service implementations (org.eclipse.equinox.http.jetty or org.eclipse.equinox.http). See [[#Secondary Goals]].

About

This project aims to add the ability to externally invoke commands in Eclipse via a web browser.

For example, this could enable a site to provide a link which would cause Eclipse to fetch and open a source code file in a single click. A sample link might look similar to the following:

<a href="http://localhost:56789?command=open_file&filepath=http://someWhereOnTheWeb/foo.java">open this file in Eclipse!</a>

Eclipse will listen for these requests and, when received, invoke the command in one of the currently running Eclipse instances.

Note: just to avoid any confusion, this example assumes that an "open_file" command has been written which supplies the aforementioned functionality.

Primary Goals

Legend

Needs some investigation
Patch in progress
Bug fixed / Feature added

Goals

Integration of a web server for intercepting remote commands.

NanoHTTPD is currently being utilized for this purpose as it is a less complex alternative to using one of the OSGi Http Service implementations (org.eclipse.equinox.http.jetty or org.eclipse.equinox.http). See #Secondary Goals.

Secondary Goals

Implement support for multiple instances (as outlined below)

this does not include support for headless Eclipse instances

Adapt to make use of an OSGi Http Service implementation

Design Ideas

Firstly, to have the server load on startup the the startup extension point will be used. This startup code will then start an eclipse job which will run in the background and behave as a wrapper around the web server.

The wrapper will do the following

check if any commands have been received by the server

if commands exist then for each command

if a handler exists for the command then forward the parameters to that handler

Dealing with multiple Eclipse instances

Special handling is necessary when dealing with multiple instances of Eclipse. For example, when a command 'foo' is received (e.g. http://localhost:34567?command=foo) and there are two or more instances running, which both support the 'foo' command, which instance should execute 'foo'?

One way to handle this could be to have one Eclipse instance act as a sort of 'main hub'. To clarify, all commands would first be received by this instance. When necessary, this main instance would forward commands to other instances. The instance that a command gets forwarded to would be chosen by the user via a dialog which lists all viable Eclipse instances (i.e. those which support the command).

Implementation Strategy

The first Eclipse instance loaded will utilize the default port (e.g. 34567) and act as the main instance as described above.

Then, when a second(or third, fourth, etc.) instance is launched it tries to obtain the default port. Since it will not be able to(because it's already in use by the main instance) it chooses a random unused port and then registers itself with the main instance which will always be found on a defined default port (34567 in this case).

Now the main instance is aware of the second. At this point the main instance can request a list of commands supported by the second instance. This will be useful for disambiguating which Eclipse instance should handle a command when there are multiple instances which can handle the same command.

So when the main instance receives a command a dialog can be shown which will list all the instances supporting the command. The user then picks which instance the request should be forwarded to.

What should be done when an instance terminates? One approach is to require that all non-main instances send ping-like messages(e.g. resending the registereclipse command) to the main instance at a regular interval. The purpose of these messages would be twofold:

It would allow the main instance to keep track of 'alive' secondary instances.

It would allow a secondary instance to detect if the main instance has terminated. The discovering instance could then take over listening on the default port and become the new main instance.

Related Bugs

[EditorMgmt] Need ability to open a file in eclipse from the command line (see bug 4922)

[launcher] way to pass arguments from launcher to a running application instance (see bug 178927)

Provide an external program to run commands in a running Eclipse instance (like gnuclient) (see bug 186147)

Schedule

Tentatively as follows:

Analysis (up until May 28):

This phase will involve interaction with the mentor to estimate the exact requirements of the project and research in order to gain more familiarity with the Eclipse framework. It will also involve setting up the project infrastructure such as the code repository.

Development Part I (May 28 - June 21):

This phase will involve the development of the code which listens for and responds to command execution requests.

Development Part II (June 22 - July 16):

This phase involves the creation and implementation of a generic way to add and remove commands.

Testing and Wrap-Up (July 17 - August 28):

This phase involves thoroughly testing each aspect of the finished project and tying up any loose ends.

Some intermingling and modification of these phases will most likely be necessary :-)

Documentation

Installation

The simplest installation route is to use the Eclipse update manager (Help > Software Updates > Find and Install...) and then add the following remote site:

Simply replace IDofCommand with the identifier of the command you want to run. As well, if applicable, replace parm1, parm2, etc. with valid parameter names and values.

Note: In the event a command actually has a parameter named "command", the first "command" value from the left will be used as the command ID and the other will be used as a parameter. So, to be safe, make sure the command you want to run is specified before any of it's parameters.