[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] [prov] p2 / browser integration
- From: Markus Alexander Kuppe <equinox-dev_eclipse.org@xxxxxxxxxxx>
- Date: Wed, 24 Oct 2007 18:58:04 +0200
- Delivered-to: email@example.com
- User-agent: Thunderbird 220.127.116.11 (X11/20070326)
> Jeff McAffer wrote:
>> At the Equinox summit there was some discussion around how to discover and communicate with existing instances of Eclipse when either someone double clicks on a shortcut or clicks on a link in a browser. There was some discussion around a Google SOC project as well as the use of commands and console integration. It would be good for someone to prototype an actual working setup here so that we can kick around various options and approaches. For the first cut there does not seem to be a need for doing native stuff (seems like an optimization). I noticed the other day that ECF has some discovery code that might make sense here as well?
> Just to add a little more detail...
> ECF has a discovery API: http://wiki.eclipse.org/ECF_API_Docs#Discovery_API
> This is a protocol-independent API for doing discovery of services (OSGi and/or other).
> We currently have two java-based provider implementations:
> 1) Zeroconf/Bonjour/Rendevous
> 2) Service Locator Protocol (aka RFC 2608)
> jSLP: http://jslp.sourceforge.net/
what kind of discovery does p2 require? Is the main use case to discover
non running Eclipse installations located somewhere on the file system
or is it to find other running instances on the same (or remote) machines?
The first use case was worked on during the GSoC project of Ogechi Nnadi
(Remy Suen and me as mentors) which is not yet ready for productive
use. Pascal and I had done some initial requirements discussion before
the student started, but nothing really formal.
The second use case can be handled by the current incarnation of ECF
already (1.2), though we plan on simplifying the API  as well as
adding at least one additional remote capable provider.
Technically both use cases are hidden behind the ECF discovery API since
it doesn't distinguish between local and remote discovery.
But at least the GSoC project hasn't been adopted to the latest ECF API
changes yet (it is even still in the soc repo).
> Both I and Markus Kuppe are actively working on the discovery API, and Jan Rellermeyer is working with us on jSLP. There are already some simplifications planned/scheduled for ECF 2.0/Ganymede.
> I can't speak for Markus and/or Jan, but would be willing to help/support/participate myself...and suspect Markus and Jan would be willing to participate as well.
I'm definitely willing to help with p2 and discovery.