User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
Hi Thomas,
On 11/21/2013 11:27 AM, Thomas Calmant wrote:
Hi
Just a small reply about properties.
I think we have 4 kinds of values to handle : strings, integers,
floats and lists (of those types)
Or at least lists of strings, like the objectClass properties.
I should have previously referred you and all to the RSA enterprise
spec chap 122.8 [1]...which gives what they call the 'endpoint
description extender' format...and supported types. I say this
because since we implement the RSA spec, we support all the types
defined in the EDEF.
In ECF's RSA implementation, the IServiceInfoFactory service is (on
host) responsible for the transition from
EndpointDescription -> discovery api service properties
and (on consumer/receiver)
discovery api service properties -> EndpointDescription
Since the types of all of the RS/RSA standard service properties are
known (e.g. String[] for objectClass)...*I believe* that the
ServiceInfoFactory default implementation simply uses Strings for
encoding these standard properties for publish via discovery API
(doesn't use serialized Long, or Float, or List or etc). For
example, with objectClass (what OSGi refers to as 'String+'...which
is either String or String[]) I believe it gets encoded within the
discovery service properties as:
or Object[] objectClass = { "fqclass1" } gets encoded in discovery
properties as: "objectClass" = "fqclass1"
And then on the receiver side...it simply reads/parses these
properties and converts them to the known appropriate type...e.g.
String[] objectNames = decode("fqclass1,fqclass2,fqclass3"); //
where decode/parsing is split(",");
I say all this because I think that given this, it may be easiest
(and most generally useful) if on the python side something be
created to implement the decode from the (jmdns) service properties
(or any discovery protocol set of service properties) to a
(RSA-specified) EndpointDescription. As with String[] (lists),
this decode is almost trivial for all the standardized service
properties...and by looking at ServiceInfoFactory I can tell you
exactly what it's doing for all of the standard properties)...and
then this could be reused in python using *any* discovery
provider...since ECF does the same thing wrt EDEF for all the
discovery providers.
Just for example/reference, below is an EDEF xml generated (via ECF
RSA) for one of our example remote services. Since all of the
properties in this example are standard ones (or ECF-specific ones),
the types are known/specified...so as I describe above...I believe
that they are encoded for discovery as String name/value
pairs...even for Long,Class[], or List types.
Of course, if there are other (non-standardized) complex service
properties for a given remote service then those will have to be
dealt with differently (perhaps via the EDEF 'xml'?).
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]?