[elvin-discuss] Re: Elvin spec

[David Arnold]

-->"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?

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

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

effectively the latter.

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

JE4 and PE4 handle unknown error codes nicely.  libelvin has been less
nice in the past; i'm not sure exactly what it's doing now.


  Matt> Enjoy the beach!

thanks, i did  :-)





d