[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] RPC for Remote P2 repositories
|
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.
Jeff
Thomas Hallgren wrote:
Hi,
I'm implementing a remote service for p2 repositories. Initially, I
chose JSON as the RPC mechanism since its simplistic, very
lightweight, and fairly mature. We've also had some good experiences
with it when we did the AOL XDrive implementation in the Spaces project.
In this case I have an Equinox based OSGi framework on both sides and
perhaps it would be far more efficient to use ECF remote services? I
have the following requirements:
1. I must be able to pass some objects by value that are neither
java.io.Serializable nor standard java beans. The only way to
serialize/deserialize them is to register custom serializers. Typical
examples are the p2 ArtifactDescriptor or ArtifactKey.
2. It must be possible to register custom serializers based on
interfaces (i.e. IArtifactDescriptor).
3. I need to pass some objects by reference. Either the RPC mechanism
must manage garbage collection internally or I must have access to
some API that allows me to do an efficient implementation. My current
JSON based implementation uses java.lang.reflect.Proxy instances in
the client, registered in a WeakHashMap. I then keep track of
object-id's that are no longer used and periodically tell the server
to drop them.
4. It must be possible to register callable references based on
interfaces.
5. I must be able to limit the access to some methods/interfaces based
on session data (isUserInRole() or something similar).
How will ECF remote services stand up to these requirements?
Regards,
Thomas Hallgren
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev