[elvin-discuss] Re: Elvin spec
matt at mattp.name
Fri Jan 5 02:16:39 CST 2007
On 05/01/2007, at 4:24 PM, Ian Lister wrote:
> On Wed, 3 Jan 2007, 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.
> FWIW I dislike the "Protocol-Subset: A" business. I'd much rather
> something more like what we do for authorisation in 4.4 e.g.
> "Supports-Subscription: 1" (or just "Can-Subscribe: 1") or whatever.
Alright, but for neatness sake it might be nice to use a prefix for
capability fields, e.g. "Capability.Subscribe", "Capability.Quench",
etc. Doesn't fit with how it's done in Supported-Key-Schemes, but...
>> 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.
> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED (implying
> the lack of support is local) you'd just give up and go home, but
> with NO_ROUTER_SUPPORT it's worth continuing to try other routers.
Not sure what the difference is? Either a request is recognised but
not supported or it's a protocol violation surely?
>> of course, it'd also be good to have this advertised in the
>> ConnRply options so the client's options callback can reject the
> And in real service discovery too: ERDP (if we continue to develop
> it), a standard DNS TXT format (for DNS-SD), and whatever else.
Hmm, I have no idea what any of that means :) But it's an opportunity
to point out that I'm thinking that advertising the router using mDNS
(Bonjour) might be a useful thing to do. Any opinions?
>> 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 ... ?
> Resist! :-)
> They're an extra feature that's only just now being deployed and
> can be added to the spec later without breakage.
> (Although if there's some incompatibility potentially caused by
> adding it later we should change the 4.0 draft spec to remove that
> and allow us to add the feature to the spec later without
> incompatibility, of course)
Yes, I think that was also the gist of my response too.
>> but i guess we should consider what you'd like to do with Avis, Matt?
> Ship it!
> Oh, sorry... :-)
Would love to ;) And in fact I think it's very close. Just need to
clear up this issue and get in a little more field-testing with the
deployment packages and then I'll qualify for my Ship It! award.
More information about the elvin-discuss