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 08:15:55 UTC