[elvin-discuss] Re: Elvin spec
matt at mattp.name
Wed Jan 10 16:06:39 CST 2007
On 08/01/2007, at 4:31 PM, Ian Lister wrote:
> 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.
OK. But I would have thought the client library would have better
ways of reporting (fixed) lack of support for a feature.
>>>> of course, it'd also be good to have this advertised in the
>>>> ConnRply options so the client's options callback can reject the
>>> And in real service discovery too: ERDP (if we continue to
>>> develop it), a standard DNS TXT format (for DNS-SD), and whatever
>> 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
> Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and DNS-
> SD (discovery). ERDP is the existing Elvin Router Discovery Protocol.
Sounds like what I want then ;) Is ERDP something that should/would
be opened up?
More information about the elvin-discuss