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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
