incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <>
Subject Re: [DISCUSSION] standard layer to exec : regCommandProxy
Date Thu, 23 Feb 2012 14:38:38 GMT
I'm on the fence as to whether we should provide the higher level
granularity (Service level).  I'm leaning towards only providing
action level granularity because it is more explicit.  I mocked up a
way of defining these in the platform file which follows the pattern
set by the platform objects and would allow for both Service level and
Action level proxies:

The exec would then simply check for Cordova.commandProxies[service]
first and then if not found Cordova.commandProxies[service + action].

I envision bootstrap taking care of registering the platform proxies.
I don't see a need to unregister.

On Thu, Feb 23, 2012 at 2:51 AM, Jesse <> wrote:
> I have been giving this some thought, and posted a gist for discussion.
> I have not included any of the require/define wrapper api's, as I wanted
> the API to be the talking point.  Ideally this would be implemented on ALL
> platforms and allow us 100% consistency in APIs calling exec.
> Dividing responsibilities, we would end up with something like the
> following:
> PluginCode ( concrete example compass.js )
> - exposes consistent API for ALL platforms
> - performs parameter checking
> ProxyCode
> - performs device specific implementation where native calls are not needed.
> CordovaJS
> - de-couples API specific differences across devices, exec is focused on
> being a device specific bridge ( or a bridge with an on-ramp ).
> An added benefit to this aproach is that it will provide us a stub point
> where we can simulate/hook tests, as currently it is difficult to test
> failing cases ( especially cases that typically should not fail )
> Some additional questions that this may bring up:
> 1. do we need lesser/greater granularity of the APIs we want to proxy? ie
> should we be able to hook all of Compass with one call, or individually for
> each method?
> 2. do we need to provide an un-register method?
> 3. is there a more descriptive name for this?
> Thoughts?...
> Cheers,
>  Jesse

View raw message