Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] iPOPO Compatible Providers
Hi Thomas,

On 11/25/2013 1:35 AM, Thomas Calmant wrote:
Hi,

I'll read the RSAdmin specs as soon as possible.
I only read the RS specs for OSGi R4, and I was based on the code from Rose [1] by Jonathan Bardin.

WRT RSAdmin I don't think anything architectural changed from 4 -> 5, so no problem there.


The aim of iPOPO remote services is to support dynamic services, i.e. which can be registered, unregistered and updated,
and to support as much values (argument, result, property) as possible, while staying transparent.

In Python, this is possible with jsonrpclib-pelix [2], which uses reflection (costless in Python) to generate a dictionary, converted to JSON using the builtin module.
The current version in Java is based on Jabsorb [3].
The difference between Jabsorb and those you cite is that it is fully based on reflection: each getter and setter will be considered as a JSON field, alas it uses a "modified hierarchy" in the JSON stream.
For example, a dictionary will be streamed like: {"javaClass": "java.util.HashMap", "map": {...}}.
I prepared a Python module to handle this kind of format.

These tools simplify the transparency of remote services.

At first sight, I thought we could interoperate quite easily, and even to replace my current implementation with ECF.
The latter point doesn't seem to be possible with requirements, as I need to be notified of service updates.

What I suggest, is that I prepare a subproject that implement (some of) RSA specifications, ike the EDEF file format, the specific serialization of properties, etc; in order to "speak the same language" as ECF.

I fully agree with this.   It would be much better...IMHO...for any work that's done in Python to principally support the RSA standardized formats (e.g. EDEF).     One reason this particularly makes sense is that ECF's provider architecture makes it 'languageless' in that for both discovery and distribution a variety of communication protocols...and serialization formats...can be used.

This includes json...in fact we distribute the json.org parser as part of the ECF distribution (and....other parsers can be used if desired).  I suppose if it makes the most sense, jsonrpclib could even be used as (one) answer to [A].

BTW...if you have any questions about RSA from looking at our docs or the specs...feel free to ask me/us...and I'll be happy to help.

thanks,

Scott

[A] https://bugs.eclipse.org/bugs/show_bug.cgi?id=421558




2013/11/23 Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
On 11/19/2013 02:43 PM, Thomas Calmant wrote:
> First, there is a "dispatcher servlet" which is bound to an HTTP
> service, and returns complete information about exported services (UID,
> endpoint name, properties, ...)
> The multicast discovery is notified by the "dispatcher core" of changes
> in exported services: endpoint added, updated and removed.

Hi Thomas,

if the dispatcher speaks JSON, we might be able to leverage ECF's
restlet provider [1] on top of GSon or Jackson.

Btw. I'm currently working on the provider to toy [2] with the EF
Greenhouse [3].

M.

[1] https://github.com/ECF/RestletProvider
[2] https://github.com/lemmy/greenhouse
[3] http://m2m.eclipse.org/demo
_______________________________________________
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

Back to the top