incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject Re: Plan for device specific APIs?
Date Mon, 19 Mar 2012 15:23:31 GMT
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