incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: [DISCUSSION] standard layer to exec : regCommandProxy
Date Thu, 23 Feb 2012 16:43:24 GMT
Can we back up a little? I want to understand, precisely, the problem
we're looking to solve.

So far the only reasoning I'm inferring is:

1. separation of concerns not at a high enough level
2. testability of cordova-js not atomic enough
3. platform specific overrides are too brute force

Am I on the right track?

(Not trying to belay the discussion but I'm seeing a whole lot of
solution without much clarity on the problems they solve.)



On Thu, Feb 23, 2012 at 7:18 AM, Gord Tanner <gord@tinyhippos.com> wrote:
> I am wondering if we should build proxying directly into the exec module.
>  This would require a generic exec module we would mix in from that would
> do this for us but I am thinking:
>
> var exec = require('cordova/exec');
>
> exec.proxy("service", "action", function (success, fail, args) {});
>
> I would expect the platform init code to have some way of linking up these
> proxies.  I would prefer it to be handled via convention over
> configuration, for example via folder structure or file name.
>
> so:
>
> lib/exec/blackberry/proxy/contacts.search.js
>
> On Thu, Feb 23, 2012 at 9:38 AM, Drew Walters <deedubbu@gmail.com> wrote:
>
>> 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:
>>
>> https://gist.github.com/1893077
>>
>> 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 <purplecabbage@gmail.com> wrote:
>> > I have been giving this some thought, and posted a gist for discussion.
>> >
>> > https://gist.github.com/1891465
>> >
>> > 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
>>
>
>
>
> --
> Gord Tanner
> Senior Developer / Code Poet
> tinyHippos Inc.
> @tinyhippos

Mime
View raw message