Talk:Eclipse Web Interface

The "Modified BSD" license on NanoHTTPD looks compatible w/ EPL, though IANAL. More info here: http://elonen.iki.fi/code/nanohttpd/

This would let you have your Eclipse plugin(s) set up to allow users to do things to a remote server, such as requesting files.

I see two possible scenarios here: Pull and Push.

If you design this to use a Pull mechanism (starts in Eclipse and accesses the remote/localhost webserver), you'd have:

1. webserver serving content (eg., a website w/ a plugin you want to install locally) -- could prototype this with a modification of NanoHTTPD or even just a bare-bones out-of-the-box Apache2 server. All the remote server would need to do is serve files.

2. Eclipse install requesting the content (eg., to request the remote/localhost file(s) and to be able do something with it (eg., install it or open it in an editor)).

Conversely, you could try to implement using a Push mechanism, where the remote/localhost server would be hit in a browser and told to install something to the local Eclipse. My concern here is that Eclipse doesn't know about the browser, so you'd have to have a listener running at all times waiting for the embedded server to get a request to do something. Once the request comes in, you'd be back to the first Pull scenario, but here you'd need to authenticate the request by popping a dialog in Eclipse:

Someone has asked to _________ in this running Eclipse instance. Accept? [ OK ] [ Cancel ]

You could implement a Preferences page to allow localhost sites to automatically authorize, and always request confirmation from remote sites; however, I wonder how useful the Push scenario is compared to Pull, considering you can surf the web from within Eclipse itself (eg., using Mylar to surf Bugzilla).

The Pull scenario is more like using Firefox to install .xpi extensions into itself; Push is more like using Internet Explorer to update Firefox, which at first glance seems like an odd use case.

Thoughts?

--nickb 11:05, 3 May 2007 (EDT)

---