cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: WebView Promise and W3C standards
Date Wed, 10 Dec 2014 20:47:55 GMT
Do we prefer to invent new cordova-specific apis, or prefer to match
standard browser apis?  When there is no browser spec to match then design
comes down to aesthetics and personal preference (as you say).  But often
there is an existing browser spec, and then it comes down to match or
fork.  I'm in the camp of preferring to match, and was under the assumption
others here were too.

Given the upcoming specs mentioned earlier (sockets, file, filesystem,
permissions, service worker, fetch), seems that fighting the adoption of
promises in core apis implies opposing the adoption of modern web specs.
 e.g. I'm assuming Andrew was referring to
http://www.w3.org/TR/battery-status/, since matching that spec *would*
require promises.


Now, as I understand, you are not saying you are opposed to adoption of
promises in Cordova, but that you are simply against the inclusion of a
polyfill directly inside cordova-js.  I think that a promises-polyfill
plugin alternative has some technical downsides [1], but they seem not so
insurmountable that we shouldn't just get passed this debate and do that.

In my opinion, we should prefer to create a common plugin (at least until
browserify), since I really hope we don't tell devs to just include their
own polyfill with each plugin.

[1]:
- Can't rely on a polyfill plugin for cordova-js itself.  There are a few
places where that may have been useful.
- We don't currently load plugins in an order that respects plugin
dependencies, so every plugin relying on promises-polyfill will have to
require() it at runtime before using  and forgetting to do so
may-or-may-not lead to an error.  Maybe we just fix this in our plugin
loader.
- It seems odd that window.Promise will exist depending on which plugins
you have installed.  While this technically isn't different than with any
plugin modifying global symbols, it seems odd-er when applied to a
dependant platform feature.

-Michal

On Wed, Dec 10, 2014 at 1:56 PM, Jesse <purplecabbage@gmail.com> wrote:

> Why does battery-status 'require' promises?
>
> I agree that promises are here to stay, but I am unclear why it would be a
> good idea to go and change/rewrite/break our apis to use them?
>
> Most of the windows plugins use promises all over the place, the entire
> async windows js api is promise based, but this has zero impact on what our
> core-api looks like to a user. The same should apply to any plugin that
> wants to depend on promises, just depend on a promise plugin, which may or
> may not add polyfil code to the dom.
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Wed, Dec 10, 2014 at 9:41 AM, Brian LeRoux <b@brian.io> wrote:
>
> > - no technical benefit (but aesthetics, sure)
> > - adds weight (payload and runtime)
> > - might interfere with userland polly
> >
> > -1
> >
> > On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > One specific spot in core I'd like to use it is to address this TODO in
> > > Android's exec bridge:
> > >
> > >
> >
> https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
> > >
> > > The actual need is for a setImmediate polyfill, but Promise does the
> same
> > > thing (with an extra object creation).
> > >
> > > On Wed, Dec 10, 2014 at 10:35 AM, Ian Clelland <iclelland@chromium.org
> >
> > > wrote:
> > >
> > > > On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve <
> agrieve@chromium.org>
> > > > wrote:
> > > >
> > > > > userland means that plugins won't be able to use them unless every
> > > plugin
> > > > > also includes a copy of the polyfill within it.
> > > > >
> > > > > Looking at our core APIs, seems maybe it's just battery-status that
> > > will
> > > > > require it. Should we have battery-status include the polyfill
> within
> > > > it? I
> > > > > hope not. I'd hate to get to where several plugins in my app all
> > bundle
> > > > the
> > > > > same polyfill.
> > > > >
> > > >
> > > > I believe that Mozilla's new File API, which I think we're planning
> to
> > > > implement, and which should be as core as File is now, is also
> heavily
> > > > promises-based.
> > > >
> > > >
> > > > >
> > > > > If we move to having the entire cordova.js built using browserify
> > where
> > > > > every plugin gets to contribute to the JS that goes into it - yes
I
> > can
> > > > see
> > > > > this solving this use-case as well. But that also seems to me like
> a
> > > much
> > > > > larger and much more controversial change.
> > > > >
> > > > > Whether you are for or against promises - they are already here.
> They
> > > > > exists natively on most latest mobile webviews, and every vendor
> has
> > > > > committed to adding them. And they are being used in *most* new
> specs
> > > > that
> > > > > I've seen (sockets, filesystem, permissions, service worker, fetch)
> > > > >
> > > > > Are there any concrete downsides to putting Promises polyfill right
> > in
> > > > > cordova-js?
> > > > >
> > > >
> > > > As long as the promise doesn't clobber the native implementation, if
> it
> > > > exists, and we can remove it completely from platforms when they
> don't
> > > need
> > > > it anymore, it seems to me like a small price for having this
> available
> > > to
> > > > all platforms. (Other opinions vary, I'm sure, though)
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Fri, Dec 5, 2014 at 4:39 PM, Joe Bowser <bowserj@gmail.com>
> > wrote:
> > > > >
> > > > > > +1 to userland. I see other approaches causing more problems.
> > > > > >
> > > > > > BTW: The only time I use promises is when the platform explicitly
> > > > > requires
> > > > > > it, and right now that's just MozillaView.  While I think it
> looks
> > > > > awesome,
> > > > > > I view Promises as a luxury right now and not a standard feature
> as
> > > of
> > > > > yet.
> > > > > >
> > > > > > I also really wish specs wouldn't rely on code that only exists
> on
> > > the
> > > > > very
> > > > > > latest browsers. It just makes life harder on people who have
to
> > > > > implement
> > > > > > stuff.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message