incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gord Tanner <g...@tinyhippos.com>
Subject Re: [DISCUSSION] standard layer to exec : regCommandProxy
Date Thu, 23 Feb 2012 17:13:02 GMT
1. Exactly.  I would think we should aim to have all javascript above the
exec call to be standard on every platform.  Currently it is at the API
level (which will be how we ship 1.5 due to time / YAGNI).   I would think
our end goal should be to have zero platform overrides (ideally) and for
those that we do have they should be small and surgical.

2. Currently we don't have a good method to test platform specific
overrides, so I would like to limit this code as much as possible.

3.  Exactly.  We have two examples of this at the moment:  A "mixin" type
approch for BlackBerry:
https://github.com/callback/callback-js/blob/master/lib/platform/blackberry.js#L10-22

This is ok but you end up with the end resulting API object spread over a
few files that is combined via black magic and builder trickery.

Next we have what I did in my pull request:
https://github.com/apache/incubator-cordova-js/pull/1

Where I just slam a whole new object on top.

I think we can all agree that both of these are not the ideal solution but
both work fine for now.


On Thu, Feb 23, 2012 at 11:43 AM, Brian LeRoux <b@brian.io> wrote:

> 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
>



-- 
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos

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