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:
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).
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].
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]?