[elvin-discuss] Re: Elvin spec

[Matthew Phillips]

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  
>>>> 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.

Sounds like what I want then ;) Is ERDP something that should/would  
be opened up?

Matt.