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/21/2013 8:52 AM, Thomas Calmant wrote:
Hi Markus,

I played a little with Zeroconf, and I'm able to send notifications (except updates).
It's still a work in progress, e.g. it doesn't registers the detected services.
The code is on GitHub [1], for more visibility.

It seems that the ECF mDNS discovery uses Java serialization, which is unreadable for Python, to transfer non-String objects in service properties.

That's true...but as you say only for non-String service properties.   Do you need non-String properties for these services?  If you just use Strings, then it shouldn't present a problem.

If you do (and they are only simple types...e.g. Integer, Float, Double, etc)...perhaps you could just use this library to read them:   https://code.google.com/p/python-javaobj/    I haven't tried it, but if it does what's published it might very well be sufficient...particularly since I *believe* that what is published for remote services discovery (the OSGi RSA-defined Endpoint Description) is actually represented as only Strings and Longs. 

Also...we can/could extend the ECF RSA impl to publish EndpointDescriptions encoded as json.  For the ECFer's:  this process of encoding the RSA data for ECF discovery is done via the highest priority instance of this service: 

org.eclipse.ecf.osgi.services.remoteserviceadmin.IServiceInfoFactory

And the default implementation is: 
org.eclipse.ecf.osgi.services.remoteserviceadmin.ServiceInfoFactory). 

For example...we could encode any complex properties in EndpointDescriptions as json very easily with a custom IServiceInfoFactory.  And then simply replace the default impl by registering a higher priority IServiceInfo.

But before creating a custom IServiceInfoFactory...I think it would be worthwhile to attempt publishing (via RSA) the service, and look at what actually ends up in the jmdns service properties for the published service.  If it's all Strings...or maybe just Strings and Longs (with python-javaobj), then it may not be necessary to encode the complex EndpointDescription properties as json (but if someone wants to take that on, I would certainly endorse that...and of course could help with the IServiceInfoFactory integration).

Scott



The current version of the Python implementation uses the JSON format for common types (lists of strings, dictionaries, etc).

[1] https://github.com/tcalmant/pelix-ecf-chat/blob/master/experiment/mdnssd.py

Cheers,
Thomas



2013/11/20 Thomas Calmant <thomas.calmant@xxxxxxxxx>
I overlooked it when I started the iPOPO remote services (1 year ago), but I didn't found an easy way to notify services properties changes (only addition and removal).
I don't know if I missed it or if it is the way the protocol works.

I still haven't looked at the org.eclipse.ecf.provider.jmdns bundle, I planned to try to mimic its behavior with pyzeroconf.
An early draft is available on my dropbox [1].

[1] https://www.dropbox.com/s/3d8dcuva4y91dil/mdnssd.py

Thomas


2013/11/20 Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
On 11/20/2013 01:52 AM, Thomas Calmant wrote:
> I got a case where services had serveral, very long properties values
> (full text strings), which implied to send packets larger than 1600
> bytes on notifications (registration and update).
> Of course, it raised the UDP packet ordering problem, so I decided to
> use multicast for small event packets only, and HTTP for information
> transfer.
> This is one implementation of a discovery protocol: other
> implementations can ignore the dispatcher servlet.
>
> Also, in this case, the HTTP server must be active for JSON-RPC to work,
> so there were no real constraint against this servlet.
> New providers can work without the dispatcher servlet without problem,
> as long as we have this "horror case" (the problematic exported service
> has been cleaned up since).


What about re-using an existing multicast-based solution like pyzeroconf
[1]?

M

[1] https://github.com/mcfletch/pyzeroconf
_______________________________________________
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