[elvin-discuss] Re: Elvin spec
ilister at mantara.com
Mon Jan 8 00:01:23 CST 2007
On Fri, 5 Jan 2007, Matthew Phillips wrote:
> On 05/01/2007, at 4:24 PM, Ian Lister wrote:
>> On Wed, 3 Jan 2007, David Arnold wrote:
>>> most important is the NACK code, i think. there's not much alternative
>>> for a client library than passing back a NOT_SUPPORTED to the application,
>>> but given it's allowable to have routers without quench, etc, it's gotta
>>> be reported somehow.
>> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED (implying the lack
>> of support is local) you'd just give up and go home, but with
>> NO_ROUTER_SUPPORT it's worth continuing to try other routers.
> Not sure what the difference is? Either a request is recognised but not
> supported or it's a protocol violation surely?
If the lack of support is local (e.g. your client library implementation
doesn't support quench) there's no request at all.
>>> of course, it'd also be good to have this advertised in the ConnRply
>>> options so the client's options callback can reject the connection.
>> And in real service discovery too: ERDP (if we continue to develop it), a
>> standard DNS TXT format (for DNS-SD), and whatever else.
> Hmm, I have no idea what any of that means :) But it's an opportunity to
> point out that I'm thinking that advertising the router using mDNS (Bonjour)
> might be a useful thing to do. Any opinions?
Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and DNS-SD
(discovery). ERDP is the existing Elvin Router Discovery Protocol.
More information about the elvin-discuss