| Re: [equinox-dev] [prov] p2 / browser integration |
So, I'm 100% for where you going as have raised concerns before (http://mea-bloga.blogspot.com/2006/10/what-eclipse-can-learn-from-firefox.html).
The problem with native stuff is that it's a pain to deal with on various platforms. In my product work, we've gone the way of #2 as that provides more flexibility in what you can instruct your Eclipse to do. In our case, this was easy as our product only ever has one instance running. This is more complicated in the typical Eclipse scenario of multiple instances... ie., which instance should respond to my download request if I have multiple Eclipse's running?
I think we can go the lazy firefox route. Firefox has a notion of an XPI package format. If you try to download an XPI within Firefox, it knows that it is something it needs to install and handles it. If you do it in IE, it has no idea what to do since Firefox doesn't registry any native/OS type things. Eclipse has a great built-in browser we can take advantage of to do something similar. If you use the Eclipse browser to browse download sites or something like EPIC, if it came across something like an .ep2 file, it would handle it? How? Via some simple SWT Browser code...
...
browser.addLocationListener(new LocationAdapter() {
public void changing(LocationEvent event) {
if (event.location.endsWith(".ep2")) {
// run really cool update code
}
}
}
...
Those are my two cents... however, I think code will speak louder than words here. I think maybe defining a packaging format similar to XPI may be a start.
Cheers,
---
Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.blogspot.com | +1.860.839.2465
equinox-dev-bounces@xxxxxxxxxxx wrote on 10/23/2007 09:11:25 AM:
> 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 application.
>
> 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.
>
> =====
>
> Thoughts?
>
> -Brett
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev