No. We have not really looked into Apache River/Jini as a possible solution, nor have we looked at Zeroconf or UPnP. Our initial effort has been to define the Etch Name Service in terms of Etch itself. In other words, to define the service in terms of its Etch API and behaviors rather than its specific implementation. The purpose of defining the service in terms of Etch is to maintain our platform and language neutrality goals and to keep the developer experience at the level of an API call.
Apache River may actually be a good 90% implementation of the behavior we are seeking here. If that is the case then we could implement the Etch API for the Etch Name Service on top of Jini and we would be good. I just do not know enough about Apache River to evaluate how realistic/practical that approach might be. It is certainly worth investigating if only as you say to learn from their experiences. -- james On Tue, Dec 23, 2008 at 1:02 AM, Niclas Hedhman <[email protected]> wrote: > On Tue, Dec 23, 2008 at 4:53 AM, scott comer (sccomer) > <[email protected]> wrote: >> this is a proposal for a name service for etch. there is a text document >> describing the >> name service and rationale, and a proposed etch service idl. >> >> the intention is to define the service interface, implement an etch scheme >> which uses it, >> and produce a reference implementation of the service which can support >> simple >> deployments and also test the etch scheme. > > How much have you guys looked at Jini (now Apache River) before? It > addresses these same concerns, possibly in other scope than relevant > here, but there are a lot of lessons learned from a now 10 year old > technology. > > Formal specs are available at; > http://www.jini.org/wiki/Category:Jini_Specifications > > > Cheers > Niclas >
