cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: WebView Promise and W3C standards
Date Wed, 10 Dec 2014 21:08:18 GMT
def think we should support those specs in our great and fabled api
audit…had not considered the load order issue

not insurmountable and probably should be a feature/fix for the plugin
loader load order …but also sort of scary… reminds me of script tags hell

on that note: we need to make browserify thing first class. whats the hold
up on that front?

On Wed, Dec 10, 2014 at 12:47 PM, Michal Mocny <mmocny@chromium.org> wrote:

> 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