[elvin-discuss] Re: Elvin spec
matt at mattp.name
Wed Jan 10 16:14:29 CST 2007
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
> Matt> OK, which at least allows Sticker's setup wizard to work (it
> Matt> uses quench to guess what presence groups are active). But
> Matt> this works is obviously more by luck than by design. And I
> Matt> know how the other client libraries will deal with it
> 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.
More information about the elvin-discuss