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

I think we’re in a serious “after you, no after you” position with respect to exceptions.

Not surprisingly, the servers are not enthusiastic about using exceptions when most browsers don’t implement or support them; they would be depending on something which mostly won’t work. But browsers are understandably unwilling to commit resources to exceptions without either server demand or a clear improvement in their product from a user’s point of view, and exceptions are now almost invisible to the user.

I don’t see how to break this deadlock.

As Roy says, going from one to zero implementations does not get us closer to Rec.


> On Jan 24, 2017, at 21:30 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
> 
> 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 06:14:08 UTC