Re: Change DOMRequest to Promise

[Jonas Sicking]

For certified APIs, I think we should start doing that as soon time
permits. Obviously the switch needs to be appropriately prioritized.
So things like must-have features for the next release should get a
higher priority.

For non-certified APIs, which might be used by 3rd party apps, the
situation is more complicated. Changing from DOMRequest to Promise
isn't a backwards compatible change. So we risk breaking 3rd party
apps when we do it.

We need to come up with a mechanism which lets us migrate APIs to
newer syntax without breaking existing content. I've been suggesting
that we stick a version number of some sort in the application
manifest so that an app can choose when it wants to switch to newer
versions of APIs.

I think proposals similar to that is being discussed elsewhere on this
list, but I haven't read through them in detail yet.

So I think the answer for non-certified APIs is: Lets switch once we
have a plan for how to make backwards incompatible API changes.

/ Jonas


On Thu, Jul 25, 2013 at 12:56 AM, Kan-Ru Chen (陳侃如) <kc...@mozilla.com> wrote:
> Hi,
>
> As I read on the sysapps wg[1] they are dropping DOMRequest in favor of
> Promise[2].
>
> Do we have plans to migrate the old APIs that use DOMRequest to use
> Promise? And the target time frame?
>
> [1] http://lists.w3.org/Archives/Public/public-sysapps/2013Jul/0042.html
> [2] http://dom.spec.whatwg.org/#promises
>
> Kanru
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[David Bruant]

2013/7/31 Jonas Sicking <jo...@sicking.cc>

> For non-certified APIs, which might be used by 3rd party apps, the
> situation is more complicated. Changing from DOMRequest to Promise
> isn't a backwards compatible change. So we risk breaking 3rd party
> apps when we do it.
>

Here is a backward-compatible plan:
Make DOMRequest inherit from Promise. Write a polyfill to do that (I guess
that'll involve a dirty __proto__ setting, but it seems worth it). Maybe
market it as an "official Mozilla polyfill" or something of this kind.
Then change *all* non-certified doc to 1) encourage to use the polyfill in
the header 2) only show examples using promises. Maybe we need some
1984-style history rewriting on Mozilla hacks post using DOMRequest. And a
post on Mozilla hacks to basically say "stop using DOMRequest!".

Maybe it won't kill DOMRequest, but that should come very close.

> We need to come up with a mechanism which lets us migrate APIs to
> newer syntax without breaking existing content. I've been suggesting
> that we stick a version number of some sort in the application
> manifest so that an app can choose when it wants to switch to newer
> versions of APIs.
>

versions. Not a huge fan :-/ Sounds like a slippery slope.

> I think proposals similar to that is being discussed elsewhere on this
> list, but I haven't read through them in detail yet.
>

Damn, I missed that discussion. I'll read the archives. If someone has a
link, I'll be happy to click it :-)

David

[David Bruant]

2013/7/31 David Bruant <brua...@gmail.com>

> 2013/7/31 Jonas Sicking <jo...@sicking.cc>
>
>> For non-certified APIs, which might be used by 3rd party apps, the
>> situation is more complicated. Changing from DOMRequest to Promise
>> isn't a backwards compatible change. So we risk breaking 3rd party
>> apps when we do it.
>>
> Here is a backward-compatible plan:
> Make DOMRequest inherit from Promise. Write a polyfill to do that (I guess
> that'll involve a dirty __proto__ setting, but it seems worth it). Maybe
> market it as an "official Mozilla polyfill" or something of this kind.
> Then change *all* non-certified doc to 1) encourage to use the polyfill in
> the header 2) only show examples using promises. Maybe we need some
> 1984-style history rewriting on Mozilla hacks post using DOMRequest. And a
> post on Mozilla hacks to basically say "stop using DOMRequest!".
>

I forgot: have devtools display a warning every single time a DOMRequest
property is being retrieved (instead of a promise property).

that is:

var allReq = SMSManager.getAll();
allReq.onsucess = () => {} // devtools warning asking to use .then instead
allReq.onerror = () => {} // devtools warning asking to use .catch instead

[David Bruant]

[god damned GMail!]

2013/7/31 David Bruant <brua...@gmail.com>

> 2013/7/31 David Bruant <brua...@gmail.com>
>
>> 2013/7/31 Jonas Sicking <jo...@sicking.cc>
>>
>>> For non-certified APIs, which might be used by 3rd party apps, the
>>> situation is more complicated. Changing from DOMRequest to Promise
>>> isn't a backwards compatible change. So we risk breaking 3rd party
>>> apps when we do it.
>>>
>> Here is a backward-compatible plan:
>> Make DOMRequest inherit from Promise. Write a polyfill to do that (I
>> guess that'll involve a dirty __proto__ setting, but it seems worth it).
>> Maybe market it as an "official Mozilla polyfill" or something of this kind.
>> Then change *all* non-certified doc to 1) encourage to use the polyfill
>> in the header 2) only show examples using promises. Maybe we need some
>> 1984-style history rewriting on Mozilla hacks post using DOMRequest. And a
>> post on Mozilla hacks to basically say "stop using DOMRequest!".
>>
> I forgot: have devtools display a warning every single time a DOMRequest
> property is being retrieved (instead of a promise property).
>
> that is:
>
> var allReq = SMSManager.getAll();
> allReq.onsucess = () => {} // devtools warning asking to use .then instead
> allReq.onerror = () => {} // devtools warning asking to use .catch instead
>

// etc.

Maybe with a link to MDN doc on transitioning from DOMRequest to Promise.
It'd be more than happy to write that piece of doc :-)

David

[Jeremie Patonnier]

Hi,

If some other browsers implement such API they move to Promise directly
which break our content any ways so I'm in favor of a hard break.
However, as David said, it could be possible to make our implementation of
Promise exposing non-standard properties that match DOMRequest. That way,
we make the move smoothly and give time to developers to adjust their code
without that version number things which is pointless in a web environment
(version number switching is less efficient and reliable than feature
detection for web developers).

Actually, for privileged apps, such a break could be handle during the
review process of the market place. For intallable/web content apps... it
breaks as soon as the user want to do something cross browsers. So don't
bother and break.

My 2cts
Jérémie


2013/7/31 David Bruant <brua...@gmail.com>

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[David Bruant]

2013/7/31 Jeremie Patonnier <jeremie....@gmail.com>

> Hi,
>
> If some other browsers implement such API they move to Promise directly
> which break our content any ways so I'm in favor of a hard break.
> However, as David said, it could be possible to make our implementation of
> Promise exposing non-standard properties that match DOMRequest.
>

Just to clarify, I didn't suggest our Promises to expose non-standard
props. Rather, I suggested that the APIs keep returning DOMRequests, but to
change the definition of DOMRequest. Basically, I'm making DOMRequest a
subtype of promise so that promise methods can be used (as .then would
return an actual Promise instance, not a DOMRequest).
I lied when I said it was a non-breaking change. If people have been doing
[[Prototype]]-related tests on DOMRequest objects (probability: 10^-100) or
tests on which properties are available in ways that would break if
inherited from promises ('then' in req) (probability: 10^-10), then their
code could break. But yeah... The likelihood is very small.

> That way, we make the move smoothly and give time to developers to adjust
> their code without that version number things which is pointless in a web
> environment (version number switching is less efficient and reliable than
> feature detection for web developers).
>

Web apps ecosystem are a different beast. Jonas suggested versions in the
manifest. I think that could work, but I'd love if that was avoided.

Actually, for privileged apps, such a break could be handle during the
> review process of the market place. For intallable/web content apps... it
> breaks as soon as the user want to do something cross browsers. So don't
> bother and break.
>

True. That could be a review criteria to enter the Mozilla marketplace.

David