Re: Issue 12: Javascript API to return promises instead of nothing.

> On Jan 26, 2017, at 10:53 , TOUBIANA Vincent <vtoubiana@cnil.fr> wrote:
> 
> Hi David and Mike,
> 
> I agree with Mike, the Exception API is AFAIU necessary to obtain consent through DNT.

We’re at cross purposes.  I didn’t question whether the API is needed; I questioned whether it is implemented/used on either end, and hence if it’s likely to get removed on the way to Rec.

> One of the question related to the new ePrivacy regulation is how third parties can obtain consent, it was apparently raised during a Q&A session and the answer provided was "Defer to the market" [1]. It would be useful to have a DNT implementation addressing this.
> 
> The regulation is also pushing from some changes in the browsers, especially to provide information and obtain consent when user first install or update a browser (see article 10 of the current draft: http://ec.europa.eu/newsroom/dae/document.cfm?doc_id=41241). This push for a significant update may solve the "After you" problem.
> 
> Regards,
> 
> Vincent
> 
> 
> [1] The only source is a tweet, the stream is no longer available https://twitter.com/Andreea_L2/status/821328127653711872
> 
> -----Message d'origine-----
> De : Mike O'Neill [mailto:michael.oneill@baycloud.com] 
> Envoyé : mercredi 25 janvier 2017 22:59
> À : 'David Singer' <singer@mac.com>
> Cc : 'Matthias Schunter (Intel Corporation)' <mts-std@schunter.org>; public-tracking@w3.org
> Objet : RE: Issue 12: Javascript API to return promises instead of nothing.
> 
> Hi David,
> 
> If you mean  the JS API, the relevant EU legal requirement is for "freely given, informed, *specific*, unambiguous" consent (in ePrivacy via "terminal settings"), which the API provides.
> Without it DNT has very little point IMO.
> Moreover we already have 2 independent interoperable implementations.
> 
> Anyway the point about promises is to make the API more usable for the modern web platform, as I have already written about ad nauseam. I only raised it again because you mentioned as something we could do as a quick win. The API still works without it, even if it irritates the developers who will have to add the asynchronous capability themselves (with unnecessary extra latency)
> 
> -----Original Message-----
> From: David Singer [mailto:singer@mac.com]
> Sent: Wednesday, January 25, 2017 9:15 AM
> To: Mike O'Neill <michael.oneill@baycloud.com>
> Cc: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; public-tracking@w3.org
> Subject: Re: Issue 12: Javascript API to return promises instead of nothing.
> 
> Hi Mike
> 
> I guess I am finding it hard to get enthusiastic about fixing a feature that’s very likely to be marked as “at risk of removal” in the CR and removed through lack of interoperable support in the PR.
> 
> 
>> On Jan 25, 2017, at 9:03 , Mike O'Neill <michael.oneill@baycloud.com>
>> wrote:
>> 
>> I don't think changing the API to return a promise changes much, it 
>> only affects the IE implementation which already does not comply with 
>> the rec anyway (does not support navigator.doNotTrack for a start).
>> Bouncer will be fixed to comply with whatever we agree in a jiffy.
>> 
>> But we may want other changes anyway so why don't we schedule a drop 
>> dead date for all the TPE changes we agree on,  say june/july, giving 
>> us a couple months or so  for the transition request.
>> 
>> -----Original Message-----
>> From: Matthias Schunter (Intel Corporation) 
>> [mailto:mts-std@schunter.org]
>> Sent: Tuesday, January 24, 2017 8:31 PM
>> To: public-tracking@w3.org
>> Subject: Re: Issue 12: Javascript API to return promises instead of 
>> nothing.
>> 
>> Hi TPWW,
>> 
>> 
>> BERT: this is very useful information.
>> 
>> Here are two process suggestions.
>> 
>> -------------
>> ANOTHER TRANSITION?
>> 
>> We should try to balance efficiency/speed and a useful outcome.
>> For me, being required to issue another transition request would not 
>> be a show-stopper.
>> I guess it also would not cause huge delay (say more than 1 month), 
>> won't it?
>> 
>> What we could do is triage changes according to two criteria:
>> 
>> (a) Are they essential to reach our goal or nice to have?
>> (b) Are they substantial or editorial?
>> 
>> If we do not have essential changes that are substantial, we will not 
>> need to take the burden of another transition.
>> We we do, there is no way around it.
>> 
>> -----
>> IMPLEMENTATION/INTEROP
>> 
>> We should soon document our implementation / interop test plans and 
>> discuss them in the group and then with the director.
>> Once we all have a joint understanding of the plans and informal OK 
>> that the plans are likely to meet the W3C requirements, then we are 
>> good to go.,
>> 
>> 
>> What do you think? Any other feedback?
>> 
>> 
>> Regards,
>> 
>> matthias
>> 
>> 
>> 
>> On 24.01.2017 14:45, Bert Bos wrote:
>>> On Tuesday, January 24, 2017 8:45:56 AM CET Schunter, Matthias wrote:
>>>> Hi Roy,
>>>> 
>>>> PS: As far as I know, W3C now allows to change the spec while 
>>>> iterating in the candidate recommendation state. I.e. no need to go 
>>>> back to WD even if we introduce changes to the API.
>>> Yes, but the exact process depends on the kind of changes:
>>> 
>>> Republishing a CR with only editorial changes simply requires a WG 
>>> decision and can be done as often as the WG wishes. It needs the 
>>> Webmaster's help, so only on Tuesdays and Thursdays, but otherwise no 
>>> need to talk to anybody.
>>> 
>>> The same holds for republishing a CR after removing features that 
>>> were already marked explicitly as "at risk".
>>> 
>>> The WG can also decide at any time to republish the CR as a WD.
>>> 
>>> But republishing a CR with "substantive changes" requires writing a 
>>> new Transition Request (with all the usual things that go into such a
>>> request) and waiting for Director's approval. If the changes are 
>>> small, such approval is likely to be quick, though.
>>> 
>>> "Substantive changes" are changes that affect conformance or add new
>>> features: i.e., any changes that can make an implementation that used 
>>> to
>> 
>>> be conforming now non-conforming, or vice-versa.
>>> 
>>> 
>>> I haven't looked at the change itself, but based on Roy's e-mail 
>>> below, it seems to be a change that affects conformance. And so it 
>>> requires writing a new Transition Request if we want the updated spec 
>>> to
>> be a CR.
>>> 
>>> I can help writing such a Transition Request, but I can't do it on my 
>>> own. I don't know enough about the history of the spec and its 
>>> implementations yet.
>>> 
>>>> -----Original Message-----
>>>> From: Roy T. Fielding [mailto:fielding@gbiv.com]
>>>> Sent: Tuesday, January 24, 2017 9:15 AM
>>>> To: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
>>>> Cc: public-tracking@w3.org (public-tracking@w3.org) 
>>>> <public-tracking@w3.org> Subject: Re: Issue 12: Javascript API to 
>>>> return promises instead of nothing.
>>>> 
>>>> Umm, the downside is that it is a normative change to the API, which 
>>>> means we go back to WD status and have zero implementations.
>>>> 
>>>> I want commitments from browsers to implement this change before we 
>>>> make it. Right now we should assume the entire API will be removed.
>>>> 
>>>> ....Roy
>>>> 
>>>>> On Jan 24, 2017, at 3:20 AM, Matthias Schunter (Intel Corporation) 
>>>>> <mts-std@schunter.org> wrote:
>>>>> 
>>>>> Hi Folks,
>>>>> 
>>>>> 
>>>>> Sites can use our javascript API to register site-wide and web-wide 
>>>>> exceptions. Currently the corresponding calls do not return any 
>>>>> results.
>>>>> 
>>>>> Mike proposed to return promises. These would allow the engine to 
>>>>> call-back to a site once it has processed a javascript request.
>>>>> This renders our API more asynchronous.
>>>>> 
>>>>> IMHO there does not be a downside to this proposal. Mike posted the 
>>>>> changed javascript API here: https://github.com/w3c/dnt/issues/12
>>>>> 
>>>>> 
>>>>> Unless somebody objects before our next call, I suggest to 
>>>>> introduce this change to our API.
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> matthias
>>>> Intel Deutschland GmbH
>>>> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
>>>> Tel: +49 89 99 8853-0, www.intel.de
>>>> Managing Directors: Christin Eisenschmid, Christian Lamprechter 
>>>> Chairperson of the Supervisory Board: Nicole Lau Registered Office:
>>>> Munich Commercial Register: Amtsgericht Muenchen HRB 186928
>>> 
>>> 
>>> Bert
>> 
>> 
>> 
>> 
> 
> Dave Singer
> 
> singer@mac.com
> 
> 
> 

Dave Singer

singer@mac.com

Received on Friday, 27 January 2017 06:12:56 UTC