|Re: [ecf-dev] iPOPO Compatible Providers|
On 11/21/2013 8:52 AM, Thomas Calmant wrote:
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:
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).