[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] RPC for Remote P2 repositories
|
Hi Jeff and Scott,
I have a prototype of a remote p2 repository server running (well, my
client consists of junit tests so far so it's not quite ready for
production). I wrote this prototype using JSON-RPC, mainly because I was
familiar with it, I knew it to introduce little overhead, and that all
communication was based on http.
The difficulty that I found (and still find) most troublesome is the
fact that many of the p2 objects cannot be serialized in a standardized
fashion. I think it would be great if relevant objects implemented the
java.io.Serializable interface or if some other generic serialization
was made available. As it stands now, I have to provide custom
marshalling for most of the objects. An approach that takes me too close
to the actual implementation to feel comfortable.
Given the nature of the p2 resolver, I found that remoting the meta-data
interface served a very limited purpose. The resolver must have access
to "everything" anyway in order to do it's job so my approach so far has
been more in the nature of a remotely controllable mirror that can serve
up entire repositories. The artifact repository however, is easier.
I'm very much in favor of having the real implementation under the ECF
and Equinox projects as I feel that this type of functionality should
fit in one or the other entirely. I'm not sure how my current prototype
overlaps with the Remote RCP Management but if what I'm doing can be
merged into this project or my requirements can be met (me contributing
of course), then that's the right way to go.
Regards,
Thomas Hallgren
Jeff McAffer wrote:
I am all for most of what you suggest. I do think that we should
separate the issues of remote p2 and remote messaging. For example it
is not clear that remote references and tc would me something we want
to get into for p2. As such, ECG should be doing the comma
infrastructre and then p2 should use that to make available it's
function remotely. This this way the story is clear to consumers and
we end up with a cleaner structure.
Jeff
On Jul 4, 2008, at 10:14 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Jeff,
Jeff McAffer wrote:
Hey Thomas
The p2 repo API has not been particularly designed to support
remoting. That is, I*Repository was not really intended to be used
as a remote interface. Frankly we just did not think of it that
way. Instead we imagined that people wanting to have a repo on
another server would implement the actual repo using whatever server
side technology appropriate (e.g., database, sql, ...) and then
implement a "client-side" I*Repository. The client side would talk
to the server using mechanisms appropriate to the configuration.
There is no expectation that the server be Java etc etc. The client
is also free to do any amount of caching etc that it wants to.
In this way the users of I*Repository are completely isolated from
the implementation details of the server and the repo implementors
are free to optimize/implement as they choose.
Does your usecase fit this model?
Of course, it would also be interesting to consider changes to the
p2 API to better facilitate remote calls. Please open enhancement
requests if you see any such opportunities.
I think it would be desirable to have a completely
separate/new/simpler API for remote p2 access rather than attempt to
modify the p2 API to facilitate transparent remote access.
Why?
1) There will likely be a number of differences in API behavior for
things like failure/exception handling, timing (e.g.
IProgressMonitor, etc), and synchronization
2) Consistent/proper handling of mechanisms like
pass-by-reference/distributed garbage collection
3) Ability to use asynch messaging, futures, as well as call/return
semantics for remote access...which is very helpful in remote
situations, but unavailable via transparent remoting
4) Ability to use multiple/various network transport bindings as per
ECF's remote services API
5) Ability to use network discovery mechanisms for remote access
(i.e. discovery API)
I would propose that ECF (with p2/Equinox/communities) should take
this on as a sub-component within the Runtime project (where ECF is
headed) and work together among interested parties.
There is already some work begun in these directions within
ECF...e.g. http://wiki.eclipse.org/Remote_Eclipse_RCP_Management
and obviously Thomas has already done some work on this as well. So
given the basic goal here (remote provisioning of Equinox/RCP/Eclipse
apps) it seems to me to be a good area for the Runtime project,
Equinox p2, and ECF.
Scott
_______________________________________________
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
