etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Dixson <>
Subject Re: naming service again...
Date Mon, 02 Feb 2009 15:59:53 GMT
What if I do not know/care about the instance name or connection
scheme at runtime. The URI:


Both the <instance> and <scheme> path elements seem as if they should
be both optional and, as suggested by 'tcp,tls", tuples. So a service
URI could be as simple as:

    etch:<api>  (or maybe also etch:///<api> )  --

    etch:<api>/<instance> --

    etch:<api>/<instance>/<scheme> --


On Mon, Feb 2, 2009 at 8:52 AM, scott comer <> wrote:
> it was pointed out to me by james that the name service was a bit confused
> in its roll by mixing up the idea of
> name translation with the ideas of failover, replication, clustering, and
> grouping of services. while those ideas
> are important in a distributed system, they deserve their own specific
> treatment and should not be part of the
> name service itself. (replication of name servers itself is needed, but
> subject to a different discussion.)
> manoj and i reviewed the proposal for name service and struck the
> requirements that were specifically not
> related to implementing a basic name service. while replication of a name
> service is still important, and
> ought to be present, we feel we could make a good first cut without the
> specific requirement and then see
> where we can go.
> so we adjusted the proposal and fiddled the wording a bit to account for the
> shift in focus:
> here are the important design principles as we see them:
> 1) a service or application should not have be overtly aware of the name
> service. it should be possible to
> deploy a service or application with or without the name service, with no
> conditional code or changes
> to code. thus use of a name service is purely a deployment consideration and
> is not required.
> 2) the name service should be supportable in a variety of styles or modes
> without changing the
> fundamental functional interface. indeed, the basic contract should be very
> simple.
> we've not updated the ns.etch file to match yet. probably today.
> thoughts? ideas? over the next few days manoj and i will publish some call
> flows and code snips to
> illustrate these ideas.
> scott out

View raw message