[elvin-discuss] Re: Elvin spec

David Arnold david at mantara.com
Tue Jan 2 20:47:51 CST 2007


On 28/12/2006, at 2:50 PM, Matthew Phillips wrote:
> On 28/12/2006, at 9:28 AM, David Arnold wrote:
>> On 22/12/2006, at 10:48 AM, Ian Lister wrote:
>>
>> ok, so: any objections to the option named
>>
>>    TCP.Send-Immediately
>>
>> being set true to mean that Nagle's algorithm should be disabled  
>> for a connection (overriding the default which SHOULD be false)?
>
> Fine by me.

ok.  i'll update and push another draft of the spec.

> Are there any other planned changes to the spec?

i *think* (bear with me, i'm at the beach, and recall is not at its  
best :-) that the major remaining issue is tidying up the error  
codes.  there's a few non-standard numbers, etc, that have crept into  
Mantara's elvind, and i'd like to make sure the spec covers the  
errors in use, and that they've got sane numbers.

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

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.

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?




d




More information about the elvin-discuss mailing list