[elvin-discuss] Re: Elvin spec

Matthew Phillips matt at mattp.name
Tue Jan 2 21:35:23 CST 2007

On 03/01/2007, at 1:17 PM, David Arnold wrote:
> On 28/12/2006, at 2:50 PM, Matthew Phillips wrote:
>> On 28/12/2006, at 9:28 AM, David Arnold wrote:
>> Actually, now I think about it, one minor thing that I would like  
>> to add is a "not implemented" NACK code for use by implementations  
>> that do a subset of the spec. Or perhaps a way to indicate that  
>> via connection options, similar to "Supported-Key-Schemes". e.g.  
>> "Supported-Protocol-Subsets: A, B".
> yeah.  i'd like to do both, actually.
> 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.

Yep. I've made up an error code for now that je4 seems to handle OK,  
which at least allows Sticker's setup wizard to work (it uses quench  
to guess what presence groups are active). But that this works is  
obviously more by luck than by design. And I don't know how the other  
client libraries will deal with it either...

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

You mean the client would request certain capabilities in the  
connection options and the router would ACK/NACK them? Or just that  
the server sends to client what it can do same as "Supported-Key- 

> as it happens, this ties in nicely with some work we did in 4.4 to  
> deal with authorisation: it's possible to disallow clients access  
> to subscription or quench (or notification).  that ended up being  
> advertised using named options.
> i'm not sure whether to try to push those options back in the 4.0  
> protocol spec, or not.  it's tempting though ... ?
> we still have to add the extra packet from the 4.1 protocol, and  
> then the authentication support from 4.4 ... i'd prefer to put that  
> into subsequent spec versions (and get 4.0 finished), but i guess  
> we should consider what you'd like to do with Avis, Matt?

Since Avis 1.0 will do the A & B subsets, the only remaining basic  
requirement for getting to release stage now is to just have a  
sensible way to advertise that, and be able to bounce C-level stuff  

So, if it's possible to back-port to 4.0 an extendable subset of  
whatever will be in 4.4 for indicating what capabilities a client can  
exercise with the router, that would seem like a sensible approach.  
Then the development path would be for subsequent Avis releases to  
track spec updates.

Enjoy the beach!


More information about the elvin-discuss mailing list