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

> On Jan 25, 2017, at 10:29 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
> 
> Hi Folks,
> 
> 
> I suggest we try to do the best technical solution to solve our
> challenge to simplify EU compliance.
> 
> 1. We analyze the problem to understand and dervice our requirements.
> 
> 2. We optimize the spec to address the requirements
> 
> 3. We provide sufficient implementations (some sites, the EFF badger, 
> Mike's plugin, potentially others)
> 
> 4. We demonstrate interop and push to rec
> 
> If this plan is viable, then only features are dropped if we realize
> that they do not make sense for our implementation: The implementors are
> part of our team and will update their implementations whenever
> reasonable and helpful. Finally, we are done and celebrate! If our
> prediction that market pull in EU increases due to regulations then the
> standard will be widely adopted.
> 
> 
> If we follow this process, then the questions are
> 
> (a) what are the new requirements that emerge?
> 
> (b) what is a good enough plan to demonstrate sufficient implementations
> and interop to get to rec?
> 
> 
> David: Would you agree?

sure, we can discuss what constitutes ‘good enough to publish’ but also discussing the ‘after you, Alfonse’ might be productive.

> 
> Any feedback/comments?
> 
> 
> Regards,
> 
> mathtias
> 
> 
> 
> 
> 
> On 25.01.2017 09:15, David Singer wrote:
>> 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 Wednesday, 25 January 2017 12:47:43 UTC