[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [equinox-dev] [prov] p2 / browser integration
- From: "Philippe Ombredanne" <pombredanne@xxxxxxxxx>
- Date: Tue, 23 Oct 2007 22:22:32 -0700
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:importance:x-mimeole; b=MHo+EsysVbPjN2+p0URq5jRgE/wPSPJ9Typ6oSetkAKn0UzztHT7Pl0gLzBUQk5QgisjWuEMuyUZL0NZDSoXYRm+LI46mc9JF3O8JbKOT7iLq2cAACtahQYdX15SYTfW9I1kxTqYKxYcwR16pOO6ePwDvwC+oln1yM8pnh38OKM=
- Importance: Normal
Could you guys check out what done of our student did this summer to address
that very issue? http://wiki.eclipse.org/Google_Summer_of_Code_2007
> -----Original Message-----
> From: equinox-dev-bounces@xxxxxxxxxxx
> [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Brett Hackleman
> Sent: Tuesday, October 23, 2007 7:11 AM
> To: Equinox development mailing list
> Subject: [equinox-dev] [prov] p2 / browser integration
> I'd like to submit this as a feature request, but wanted to
> solicit feedback here first. Apologies
> for the long post.
> (BTW, in this feature request I'm a bit loose with the
> terminology re: site.xml, features, etc... I
> realize this has all changed in p2, but I'm sticking with the
> old terms since they make more sense
> in this discussion).
> One of the major pain points with the old UpdateManager is
> that users must create remote sites by
> typing the update site URL manually into the UM dialog. 9
> times out of 10, the URL is copied &
> pasted from the browser, and the user is most likely going to
> install the only feature available in
> the site.xml (as advertised on the web page he copied the link from).
> I see two possible approaches for providing better
> integration between the browser and Eclipse.
> Both assume we have a native application capable of handing
> the site URL and other information into p2.
> 1. Register a file handler for the meta-data file extension
> with the OS. The browser would then
> prompt the user to download or open the file using the
> associated file handler. This would require
> a custom and unique file extension (*.ep2) to avoid conflict
> with other applications.
> 2. Register a URI handler (such as eclipse://) with the OS.
> The feature publisher would build a
> link to his update site URL (and possibly the name of the
> feature to be auto-installed). When
> clicked, the browser will pass the entire link to our native
> Once the native application has been launched with this site
> information (whether by URI or file
> extension), it would need a way to pass the information to
> the p2 install agent. Of course we may
> have 0-N eclipse instances running (with 0-N p2 agents as
> well?) so we would need to handle each of
> these scenarios. At first glance the safest and most
> flexible approach might be to store the
> site/feature information to a temporary file where a p2
> directory watcher could find it.
> I realize this is a fairly complex scenario, but it would
> enchance the user experience considerably.
> Some best practice docs and a few sample Eclipse feature
> download button images (seach for
> "Firefox extensions" and notice the Firefoxy install buttons)
> would go a long way, and possibly
> encourage early-adoption of p2 by feature providers.
> equinox-dev mailing list