[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Remote deployment
|
Hi Leen,
Leen Toelen wrote:
Hi Jan,
I know you've already written this for r-osgi, but do you think
there's a lot that needs to change for the ecf port? How would you do
an ecf implementation? How I see it (in the GUI at least) is that you
select a contact, send him the plugin, and the contact only has to
agree.
If you are sending a single plugin, this use case is provided by the ECF
file transfer API...at least the sending/receiving the bundle jar file.
After receiving, to install the bundle in the local runtime requires
using (e.g.) BundleContext.installBundle(...).
I don't know yet how we have to negotiate dependencies, because
you only want to send the files that are absolutely necessary.
This is where p2 would/does come in.
In p2, the 'sender' would make available (or point to) meta-data and
artifact repositories...that the receiver can then access during a
p2-based install. The meta-data and artifact repositories are
identified by a URL. The ECF filetransfer API is used *by p2* to
actually retrieve the artifacts/jars from the artifact repository (note
this is different from the case described above, where some appliction
would explicitly initiate the file transfer for the plugin and to the
install via installBundle).
p2 will do all the dependency resolution. That is, the p2 resolver will
make sure that the necessary plugins (from meta-data repo) can be
resolved and then downloaded and installed.
So for using p2, something like these steps would likely be involved
a) Sender sets up p2 meta-data and artifact repositories...and then
publish them so they can be used during the receiver's p2-based install
(via http for example)
b) The sender has to communicate some URLs for the appropriate meta-data
and artifact repositories to the receiver
c) The sender has to communicate an 'installable unit' (aka IU a p2
concept) to the receiver
d) Given the URLs from b, a working server from 'a', and the installable
unit from 'c', the receiver can/could install the installable unit.
ECF can/could be used to communicate the URL and IU meta-data to the
receiver (b and c), and have a user-level messaging dialog (e.g. do you
want to install this?...etc). This could be done via ECF datashare API
over IM, or the remote services API (which can use r-OSGi as an
implementation, or XMPP, or others).
p2 uses ECF's filetransfer APIs for the p2 client to retrieve plugins
from the artifact repository, so that will all be done transparently
(i.e. via pull). With p2 you don't have to worry about transferring the
files directly.
Does this make sense?
Jan...I know you haven't been involved-in/working on p2, but would this
still fit in with your plans?
Scott
Regards,
Leen
On Fri, Apr 11, 2008 at 12:09 AM, Jan S. Rellermeyer
<rellermeyer@xxxxxxxxxxx> wrote:
Hi Leen,
unfortunately, I didn't get an application for this project but I would be
very much interested to get somebody working on this. If we can't find a
student via GSOC, I could try to announce the project as a lab or semester
thesis at ETH but it then probably won't start before the fall semester.
Cheers,
Jan.
------------------------------------------------------------
ETH Zurich, MSc Jan S. Rellermeyer,
Information and Communication Systems Research Group (IKS),
Department of Computer Science,
IFW B 47.1, Haldeneggsteig 4, CH–8092 Zürich Tel +41 44 632 30 38,
http://www.iks.inf.ethz.ch
------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev