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
http://www.zeroconf.org/
2) Service Locator Protocol (aka RFC 2608)
http://en.wikipedia.org/wiki/Service_Location_Protocol
jSLP: http://jslp.sourceforge.net/
anyone willing to look at this and
do
a prototype?
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.
Scott
Jeff
Forgot to mention some simple approaches we could
also consider for the UpdateManager:
1. The UI could detect a standard http:// site or feature URL on the
clipboard,
or allow the user to
paste it easily into the main UM dialog without forcing them to "Add
Remote Site..."
or even better,
2. The UI could allow links to be drag and dropped from the browser,
into
the main Eclipse workbench
or the UM, kicking off the install. Providing sample "Eclipse
package, drag to install" graphics
for use on the web could make this more intuitive.
(Susan, I haven't looked at the new UI yet, so please forgive me if
some
of this is no longer
applicable)
-Brett
Jeff McAffer wrote:
>
> I agree that forcing people to browse via Elcipse is unfortunate.
It
> will address some of the usecases but not all.
>
> As for XPI, I'm not sure we need to define some new packaging. We
have
> the p2 stuff so all we really need to do is give p2 enough data
that
is
> knows what it is to install. In theory this could be as simple
as the
> ID and version of an IU. p2 does the rest based on the current
settings
> etc of the agent. XPI seemed like overkill in our situation.
>
> Jeff
>
>
>
> *Andrew Overholt <overholt@xxxxxxxxxx>*
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>
> 10/23/2007 11:10 AM
> Please respond to
> Andrew Overholt <overholt@xxxxxxxxxx>; Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>
> To
> Equinox
development mailing list <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re:
[equinox-dev] [prov] p2 / browser integration
>
>
>
>
>
>
>
>
> Hi,
>
> * Chris Aniszczyk <zx@xxxxxxxxxx> [2007-10-23 10:36]:
> > If you use the Eclipse browser to browse download sites
or something
> > like EPIC
>
> While I completely agree that we need some easy method of
installing
and
> that it would be ideal to do so from a web browser, wouldn't this
> solution require one to basically do all of their browsing from
within
> Eclipse?
>
> As hard as it will be, I think native handlers are the way to go
here.
> I'd love to be proven wrong, though, because I know how difficult
it
> will be -- especially with multiple running Eclipse instances.
>
> Andrew
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Brett R. Hackleman
Vice-President
Band XI International, LLC
11362 E. Whitethorn Dr.
Scottsdale, AZ 85262 USA
Mobile: (602) 326-7374 GSM
email: bh@xxxxxxxxxx
web: http://www.bandxi.com
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
|