W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2013

Re: [discovery-api] Supporting UPnP devices

From: Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Date: Thu, 21 Mar 2013 00:01:39 +0100
Message-ID: <514A3FD3.4010404@telecom-paristech.fr>
To: Rich Tibbett <richt@opera.com>
CC: public-device-apis@w3.org
I am not just "resisting change" or "going against progress".
I am balancing the cost of the change with what it brings, with what it 
I admire the simplicity of the current API.
This change is ruining that simplicity. That is the cost I do not accept.

My mention of a full implementation was just to establish how serious I 
am about this spec, even if I follow this WG from a distance.

Actually, the implementation is "a bit more than full": I implemented 
NSD +  service advertising for both UPnP and Bonjour
(as well as UPnP messaging support, but I know you are not interested in 
I cannot wait for discussions of service advertising to start...
Best regards

On 20mars 20:39, Rich Tibbett wrote:
> Jean-Claude Dufourd wrote:
>> I have currently a full implementation of the current spec.
>> The only problem I have is the "name" field, which I implement in a
>> non-standard way so that it works in my usage scenarios.
>> On one hand, this proposal is well designed, and on the other hand, it
>> is definitely overkill to solve the only problem I have with the current
>> spec.
>> So no, I am not in favor of this rather extensive change.
>> Best regards
>> JC
> I certainly feel this pain (having to rewrite both the spec and an 
> impl). It is the price that is paid for living on the bleeding edge of 
> emerging standards. (Also, kudos to you for getting an implementation 
> up and running. Would love to hear more about it on this list! We 
> _really_ need to kick-start some serious testing discussion now that 
> multiple implementations are starting to emerge).
> Unfortunately, I think spec changes are an occupational hazard of 
> implementing from W3C Editor's Drafts which are, by their very 
> definition, unstable and subject to changes. _If_ we have good reasons 
> to make a change to s specification then it would be better to do that 
> earlier (i.e. now) than ignore potentially valid and beneficial use 
> cases in the long run.
> My suggestion is that we snapshot and publish the current 
> specification and you can then claim compliance* to this permanent, 
> dated Working Draft version of the specification.
> - Rich
> * 'compliance' only in the sense that the implementation has been 
> written in good faith to reflect the specification - not that it has 
> passed any (currently non-existant but ultimately necessary) 
> compliance test suite.
Received on Wednesday, 20 March 2013 23:02:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:58 UTC