[elvin-discuss] Re: Elvin spec

[Matthew Phillips]

On 08/01/2007, at 11:21 PM, David Arnold wrote:
> -->"Matt" == Matthew Phillips <matt at mattp.name> writes:
>
>>> 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.
>
>   Matt> Yep. I've made up an error code for now that je4 seems to  
> handle
>   Matt> OK, which at least allows Sticker's setup wizard to work (it
>   Matt> uses quench to guess what presence groups are active). But  
> that
>   Matt> this works is obviously more by luck than by design. And I  
> don't
>   Matt> know how the other client libraries will deal with it  
> either...
>
> what code did you use, out of interest?

Top of the quench error range: 2299. Makes sure it looks bogus but  
still handled semi-intelligently by clients (je4 reports unknown  
error but seems to get the idea that it's not on the client side).

>   Matt> Since Avis 1.0 will do the A & B subsets, the only remaining
>   Matt> basic requirement for getting to release stage now is to just
>   Matt> have a sensible way to advertise that, and be able to bounce
>   Matt> C-level stuff appropriately.
>
> i think we can actually get away with returning a Nack only.
>
> no existing client library (with the possible exception of libelvin
> 4.4.x) would understand that advertisement of the feature set  
> anyway ...

OK. The (non-existent) Avis Java client library won't have quench  
either in the first release, so I guess knowing whether the router  
supports it is interesting but academic.

So, if we can get a NOT_IMPL error code spec'd, that's all I need.

Matt.