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 Thu, 11 Dec 2014 02:38:54 GMT
Jesse: yes, that could work.  By setting your polyfill to <runs/> you'll be
sure it is available after pluginsready (and thus deviceready).  For
plugins that use Promises during bootstrap, which is unlikely to be common,
the explicit require() on the polyfill is still an option.

Regarding your Native injection suggestion: how early on in the boot
process can we do this?  i.e. do you modify the startPage to inject this
before loading cordova.js, or do you do it in response to an exec bridge
call, making the timing about equivalent to the js polyfill?

-Michal

On Wed, Dec 10, 2014 at 8:35 PM, Brian LeRoux <b@brian.io> wrote:

> we should move browserify to main and drop that insane concat code
>
> its not heavyweight at all. it creates a hash in iife with deps mapped
> in…as to why dep mgmt is better than concatenating…I don't think we need to
> waste our time talking about that!
>
> On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > There's something implemented behind a --browserify flag, but not sure
> what
> > it does.
> >
> > Totally in favour of having CLI / plugman concatenate plugin JS with
> > cordova.js, but not convinced that browserify is the right tool for this,
> > as it seems quite heavy-weight for just concatenating things. If someone
> is
> > going to resume work on it, would love to hear a summary of what problems
> > it's solving (if more than concatenation), and why something more
> > light-weight wouldn't be better.
> >
> > On Wed, Dec 10, 2014 at 4: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