[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Race conditions with remote provider
|
On 7 Jun 2011, at 01:05, Scott Lewis wrote:
>> On the plus side, I've now got a much better idea of how the discovery stuff hangs together. I think there's also a lot of opportunity to make an abstract container to make it easier to provide discovery containers in the future. Quite a lot of the specific provider calls boil down to 'make this available' and 'tell me when a service arrives'. But there's a lot of glue code (turning ServiceProperties into a Map<String,String>, managing the set of services, standard implementations of notifying when services come and go etc.)
>
> Have you consulted the AbstractDiscoveryContainerAdapter class in org.eclipse.ecf.discovery? i.e:
>
> http://download.eclipse.org/rt/ecf/3.5.1/javadoc/org/eclipse/ecf/discovery/AbstractDiscoveryContainerAdapter.html
Yes, I'm subclassing this. But there's still quite a lot of behaviour which could get reused in a more specific subclass, like managing the Set of services (and providing simple implementations of the getServiceTypes and getServiceForType) as well as glue code which is commonly needed (e.g. converting map-of-string-and-byte[] to/from map-of-string). Ultimately, the glue bits outside of 'make this known' and 'discover this'. For example, the ZooKeeper overlays the properties with specific encodings for the weight/priority etc.
>
>> I'll have a go sometime at putting up a proof of concept on GitHub when I get a chance.
>
> That would be terrific, thanks. If you like we can either add it to the ECF github repo at: http://github.com/ECF or we can/could add it as a contribution to the EF git repo. Your choice of course.
More than happy to add it as an ECF contrib, but I'd really like to get practice in the GitHub process. But still, I also need to prove it works too ...
Alex
