incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Dixson <dixs...@gmail.com>
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:

    etch://<name_service_ip:port>/<api>/<instance>/<scheme>

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:///etch.examples.perf.Perf
             etch:etch.examples.perf.Perf

    etch:<api>/<instance> --
             etch:etch.examples.perf.Perf/foo
             etch.etch.examples.perf.Perf/foo,bar

    etch:<api>/<instance>/<scheme> --
             etch:etch.examples.perf.Perf/foo/tcp
             etch:etch.examples.perf.Perf/foo,bar/tcp
             etch:etch.examples.perf.Perf/foo/tcp,tls
             etch:etch.examples.perf.Perf/foo,bar/tcp,tls



--
james



On Mon, Feb 2, 2009 at 8:52 AM, scott comer <sccomer@cisco.com> 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:
>
> http://cwiki.apache.org/ETCH/etch-name-service.html
>
> 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
>
>
>

Mime
View raw message