incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Proposal for a new Plugin.execute() signature on Android
Date Tue, 25 Sep 2012 14:33:28 GMT
Summarizing what I think I'm hearing:

The current exec signature will currently:
(a) automatically parse JSON arguments, and
(b) automatically move async calls onto a background thread.

While both of the features simplify plugin developers in most cases,
sometimes manual control is desired (ie, for the two bugs you link to).

That sounds reasonable, however, I think I'm also hearing a proposal to
replace the existing execute signature (deprecating the current one).  If
for the majority of cases we are happy with the current signature, then is
there perhaps a less intrusive solution?  Or maybe we aren't happy with the
current signature, and this new signature is generally more future proof,
more performant, etc, giving us other reasons for changing?  Also, how does
this compare with other platforms?

-Michal


On Mon, Sep 24, 2012 at 11:50 PM, Andrew Grieve <agrieve@google.com> wrote:

> Means to address two bugs:
>
> https://issues.apache.org/jira/browse/CB-1530
> https://issues.apache.org/jira/browse/CB-1532
>
> I wanted to gather some opinions from those who have been around for
> longer. Here is the proposed change:
> https://github.com/agrieve/incubator-cordova-android/compare/ft3
>
> My main motivation is for FileTransfer, I need to register the transfer
> synchronously so that a subsequent abort() will not have a race condition.
> I then perform the transfer in a background thread. I *could* implement
> this using the current signature by returning true in isSync() and then
> returning a NO_RESULT result, but I think the intentions are clearer with
> the new signature.
>

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