cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: WebView Promise and W3C standards
Date Wed, 10 Dec 2014 23:52:45 GMT
So far I have approached browser polyfils with an outside-in approach.
For example, there are issues in the C# + WP8 browser implementation of
XMLHttpRequest  which prevent xhr calls to the local filesystem.  This
could have been resolved by adding platform specific code to cordova-js,
but my solution was to patch this from the native side, and supplement the
cordovaview itself.

Would it make more sense to do a similar thing with Promises? ie. Inject
them from the native side where they do not exist.

Also, about the plugin loader. We force users to wait for the deviceready
event before calling any of our apis, is it reasonable to make them wait
for deviceready before using Promises?

I slapped together a quick plugin based on the es6-promise, this works on
wp8 which does not have intrinsic promises, but only after device ready.

https://github.com/purplecabbage/promiscuous



@purplecabbage
risingj.com

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

> We haven't worked on it, also curious.  Anis, perhaps?
>
> On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux <b@brian.io> wrote:
>
> > 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