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

Received on Wednesday, 25 January 2017 22:00:36 UTC