|Becky Gibson||Mar 19, 2012 7:45 am|
|Drew Walters||Mar 19, 2012 7:54 am|
|Gord Tanner||Mar 19, 2012 7:58 am|
|Patrick Mueller||Mar 19, 2012 8:23 am|
|Becky Gibson||Mar 19, 2012 9:16 am|
|Patrick Mueller||Mar 19, 2012 9:37 am|
|Becky Gibson||Mar 19, 2012 10:15 am|
|Jesse MacFadyen||Mar 19, 2012 10:37 am|
|Filip Maj||Mar 19, 2012 10:42 am|
|Filip Maj||Mar 19, 2012 10:46 am|
|Patrick Mueller||Mar 19, 2012 11:09 am|
|Becky Gibson||Mar 19, 2012 12:08 pm|
|Filip Maj||Mar 19, 2012 12:15 pm|
|Patrick Mueller||Mar 19, 2012 1:45 pm|
|Subject:||Re: Plan for device specific APIs?|
|From:||Becky Gibson (gibs...@gmail.com)|
|Date:||Mar 19, 2012 9:16:03 am|
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 <pmue...@gmail.com> wrote:
On Mon, Mar 19, 2012 at 10:54, Drew Walters <purd...@gmail.com> 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 https://issues.apache.org/jira/browse/CB-280 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 http://muellerware.org