incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <>
Subject Re: Plan for device specific APIs?
Date Mon, 19 Mar 2012 16:16:26 GMT
Ok, so I understand the desire for the JS to be "unified" for development
and testing purposes however,  we still do have device specific versions of
the main Cordova javascript  file. Thus,  I don't see why we can't add the
device specific API's that were already there, back into the "main" JS?  If
we do not, then we have broken the existing apis.  A person that was using
the iOS device specific contact apis, now has to add in a plugin and modify
their code to use a different namespace for these apis.

I agree with Pat,
>I continue to dream of the day when all our
>existing "plugins" are structured as 3rd party plugins anyway.

However, I don't believe we plan to get to this goal for 1.6. I also don't
believe we will have a mechanism for the user to modify a "standard" file
to select just the features they want in the main cordova js file or to
extend existing objects in the JS file for 1.6?   Thus, when this does get
implemented they will again have to modify their code to adjust the api's.
 I think it would be best to mitigate as much of this churn as possible.
IOW I'm advocating for adding the device specific api's into the 1.6 main
cordova js file with the idea that eventually they could be removed when we
provide a user option to selectively add them back in.


On Mon, Mar 19, 2012 at 11:23 AM, Patrick Mueller <> wrote:

> On Mon, Mar 19, 2012 at 10:54, Drew Walters <> wrote:
> > In the short term you can look at how BlackBerry uses the 'objects' and
> > 'merges' objects in the platform file to do complete replacement or api
> > level overrides.
> The only problem with this, is that we end up pulling in the original
> common source, as well.  For instance, if you look at
> pkg/cordova.blackberry.js, you see that it includes the common
> cordova/plugin/notification module, as well as
> the cordova/plugin/blackberry/notification module.  But the one used in the
> end is the blackberry one, and so the common one is just wasted bytes.
>  Hopefully no one is accidentally using the common one between the time the
> common is set up and the blackberry one is installed.
> Issue may help with this; eg,
> blackberry can provide it's own 'cordova/plugin/notification.js' module,
> which at build time would override the common one.  The build would need to
> be a little smarter to do this, but not much.
> It's not a perfect answer, because it's crude - we would be allowing file
> overwriting by the platform.  What if you to want to NOT have one of the
> common module files, for some reason - how do you 'delete' it, in the
> platform?  We might just say: "there is no deletion, just create an empty
> module in the platform directory, and we'll end up creating a zero-line
> module".  Perhaps you'd want to throw an error in that 'empty' module, just
> to make sure no one is using it, accidentally.
> I'm not sure we would even run into this case.
> But there's another complication that may arise here.  Once we split the
> plugins directory into a set of directories per plugin (instead of having
> them all lumped together as now), what does 'override' mean?  Do we
> override the entire directory?  Or merge them?  Merge sounds better, but
> obviously I think we'd need to see how well this would work for realz.
> Perhaps a better way to think about this is, what do we want 3rd party
> plugin developers to do?  I continue to dream of the day when all our
> existing "plugins" are structured as 3rd party plugins anyway.
> --
> Patrick Mueller

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