[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Investigating some alternative update manager
|
I'd like to be involved with this effort. However, I think that we
look at providing updates to bundles/plugins, rather than features.
Features are an out-moded concept that could easily be handled by a
feature-bundle. Besides which, there are many more uses that people
will be able to have to update individual bundles (e.g. a
xerces/log4j/junit/testng implementation) and the current
'feature-based' approach is wrong. (For example, there's a 'Batik'
feature and a 'Batik' plugin currently as part of (I think) BIRT;
there's a Xerces feature for the Xerces plugin etc. The only reason
these features are there is because the update manager can't handle
updating bundles/plugins.
Secondly, I really think that each bundle-version should be able to
produce an Atom entry (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=127236 and
http://alblue.blogspot.com/2006/09/eclipse-why-update-site-should-be-atom.html).
You can then amalgamate as many plugins as you want into an Atom feed;
you then can use Atom feeds as the URL for the updates for a bundle.
(A feature could then be a single Atom feed, for example.)
Note that Atom feeds are valid XML documents; are namespaced; and can
be used to transmit any arbitrary XML content; so whatever sub-XML
format is used to represent a bundle and its required dependencies
(and versions), the Atom entry can be used to transport it in a known
header and with known update time/name/metadata associated with it
(including, for example, copyright information and where it was
originally downloaded from). As an extra bonus, Atom-parsing APIs are
available already, and aggregators (e.g. Planeteclipse) are known; an
internal update site could be expressed as an atom aggregator.
Alex.
On 14/09/06, Philippe Ombredanne <pombredanne@xxxxxxxx> wrote:
All:
just a heads up.
We are embarking on trying to provide an alternative update UI, and
possibly alternative transports, like BitTorent (using Remy's clean room
Bittorent implemantion
http://wiki.eclipse.org/index.php/ECF_BitTorrent_Provider ), and http
refinements (suspend/resume, threading).
The fun takes place mostly on IRC in and #easyeclipse
We did put a wiki page there :
http://eclipsewiki.editme.com/UpdateManager
(feel free to comment/add to the page)
and the code (early, crappy and mostly non working) is there:
http://easyeclipse.cvs.sourceforge.net/easyeclipse/easyeclipse/easyupdat
e/
This is a community effort, with the intent to :
- provide some working code
- be a place for experimentation
- provide alternative inputs for any revamp work that could happen in
the platform itself.
Peace.
--
Cheers
Philippe
philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://easyeclipse.org - irc://irc.freenode.net/easyeclipse
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev
