Comments inline below.
On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve <agri...@chromium.org>wrote:
> Created a bug for the file moving part (CB-2214), but we can
> continue discussing here.
>
>
> On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <agri...@chromium.org>
> wrote:
>
> > Jesse, thanks for the explanation. Certainly my experience is just with
> > Android & iOS, so it's good to get opinions from the other platforms.
> >
> > I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in all
> > of the shared plugin modules and hooks them up with the common bootstrap.
> > Why do you say that WebOS shares hardly any code?
>
What I meant about WebOS, was just that it overwrites most of the APIs.
There is a distinct difference in the way the platforms without a native
counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
> >
> > Blackberry certainly seems to be a bit different in that it looks like it
> > is actually 4 platforms in one. Not sure why we don't just make it four
> > separate platforms. Gord?
> > That said, Blackberry uses the module system even more than other
> > platforms. I think it would be a lot of work to make plugin within
> > blackberry have it's own loading logic that selectively loads module
> based
> > on the sub-platform (if we went with a single-file pre-built approach).
> >
> > With the single-file prebuilt approach, I'd guess it would look something
> > like this:
> >
> > plugin.xml says which .js file to include for the platform:
> >
> > <platform name="android">
> > <source-file src="filetransfer.js" />
> > </platform>
>
And maybe even:
<platform name="android">
<source-file src="filetransfer-common.js" />
<source-file src="filetransfer-android.js" />
</platform>
...
> >
> >
> > There is certainly a bug-report advantage to having each in its own .js
> > file. If everything is in cordova.js, and we get bugs with "Error on line
> > ##", we can't actually map that to a file. On the other hand, each
> platform
> > has bootstrap logic that must come after plugins are loaded. This might
> > turn into a source of errors if we have a bunch of .js files being added
> > via <script> tags.
> >
> >
> > One aspect of plugin JS that I don't want to lose, is our separate pass
> of
> > module -> symbol (defaults/merges/clobbers). In fact, I think this is an
> > area that we may wish to enhance in the future. E.g. a couple of releases
> > ago we added the ability to print a deprecation message when old
> namespaces
> > are referenced. Other advantages of the system:
> > - Helps authors write modules side-effect free modules
> > - Allows us to detect symbol collisions
> > - Gives us control over when the modules are loaded
> > - e.g. We could add measurement to see how long this process takes
> > - e.g. We could experiment with lazy-loaded modules by using JS
> > getters that return require(module)
> > - e.g. We could use this to support exposing Cordova APIs to iframes
> >
> >
> > It might be possible for us to maintain the module->symbol mapping system
> > if we had plugins use pre-built .js files. E.g. their .js could be a
> > collection of cordova.define() calls, followed by a
> > cordova.registerModuleMappings() call. Is that what you're thinking?
>
Yes, something like this.
The plugin would be wrapped in a module-closure, and 'define' it's
interface.
cordova.define("my/namespace", function(require, exports, module) { });
Some of this would need to reworked as currently we have 2 aliases for
every plugin:
navigator.accelerometer === cordova.plugin.accelerometer
> >
> > In either way, I think I'd like to go ahead with this change of moving
> > from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
> > this is a good first step for either proposal.
> >
> >
> >
> > On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <
> purplecabb...@gmail.com>wrote:
> >
> >> Hi Andrew,
> >>
> >> Having spent some time with this, I don't think it's awful, but I am
> >> worried about complexity.
> >>
> >> To me, a better approach is:
> >>
> >> - all plugins are simply ripped out of cordova-js
> >> - each plugin is distributed 'built' meaning for an API like file or
> >> contacts, there is only 1 js file, and while it depends on cordova.js,
> >> it is not part of it. ( or possibly just a concat )
> >> - plugman does the work of adding/removing but it is really just
> >> changing script tags for the js portion
> >>
> >> This means all our core plugs will need to be modified as the
> >> currently depend on the builder to wrap them.
> >>
> >> I spent some time working with your approach Andrew, and I think it
> >> sounds better than it is. Blackberry has 4 inter-related branches to
> >> consider, webos shares hardly any code with the other platforms, ... I
> >> am more keen on adding consistency than I am to making the tool work
> >> around it.
> >>
> >> If we were only concerned with iOS, Android, and windows phone, then
> >> your approach might be best, but there are some messes in there.
> >>
> >> I will continue to push for the simpler solution, but I won't block
> >> you anymore.
> >> I do think you should dive a little deeper into your approach, and
> >> possibly prove me wrong. I am completely open to further discussion on
> >> the point.
> >>
> >>
> >> Cheers,
> >> Jesse
> >>
> >> Sent from my iPhone5
> >>
> >> On 2013-01-10, at 8:09 PM, Andrew Grieve <agri...@chromium.org> wrote:
> >>
> >> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gtan...@gmail.com> wrote:
> >>
> >> > Ideally the require paths should stay true to the following rules (not
> >> that
> >> > we follow them exactly now but we are close):
> >> >
> >> > 1. should always start with cordova (in case we ever share a require
> >> > framework)
> >> > 2. should follow as close as possible to the folder structure.
> >> >
> >> > We don't really do this now (but we are close). It is mainly to help
> >> with
> >> > navigation of the project from a require statement:
> >> >
> >> > var foo = require('cordova/plugin/foo/submodule')
> >> >
> >> > Ideally I should be able to navigate to a file that lives in:
> >> >
> >> > ~/cordova.js/plugin/foo/submodule.js
> >> >
> >> > But realistically we are probably going to see:
> >> >
> >> > ~/cordova.js/plugin/foo/js/submodule.js
> >> >
> >> > Assuming we are dumping everything into a js folder here is the
> >> "mapping"
> >> > off the top of my head:
> >> >
> >> > var foo = require('cordova/plugin/foo')
> >> > ~/cordova.js/plugin/foo/js/index.js
> >> >
> >> > var foo = require('cordova/plugin/foo/ios')
> >> > ~/cordova.js/plugin/foo/js/ios.js
> >> >
> >> > var foo = require('cordova/plugin/foo/blackberry/qnx')
> >> > ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> >> >
> >> > What does a plugin (native and js code) folder structure look like?
> >>
> >>
> >> Have a look at this plugin: https://github.com/shazron/KeychainPlugin
> >>
> >> With the JS changes I'm proposing, it would look like:
> >> /src/ios/*.h, *.m
> >> /www <- empty!
> >> /src/js/common/keychain.js
> >> or
> >> /src/js/ios/keychain.js
> >>
> >> So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
> >> within cordova-js, is that when they move out, there will be the
> mapping:
> >> cordova-js/plugin/$PLUGIN_NAME ---> $PLUGIN_REPO/src/js
> >>
> >>
> >> When a plugin is installed into a project via cordova-cli, I suggest
> that
> >> we get a structure like this:
> >>
> >> MyApp/platforms/ios/... same as before ...
> >> MyApp/cordova-js/... copy of cordova-js
> >> MyApp/cordova-js/plugin/keychain/common/keychain.js
> >> MyApp/plugins/keychain/plugin.xml
> >> MyApp/www
> >>
> >> So, the idea here is that the cordova-js will have no top-level plugin/
> >> directory, but one will be added when plugins are added.
> >>
> >> Also, like other sources, .js file should be listed in the plugin.xml so
> >> that they can be reliably removed.
> >>
> >>
> >>
> >> About the require paths. I think for files in cordova-js, the prefix
> >> should
> >> be "cordova/", but for plugin files, it should be "plugin/" (or maybe
> >> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
> >> cordova modules.
> >>
> >> For the keychain example: require('cordovaplugin/keychain/keychain')
> >>
> >>
> >> In terms of changes to the builder, we'd need to add the idea of
> multiple
> >> roots. Instead of just 'lib', there will also be 'plugin' as a root.
> >>
> >>
> >>
> >>
> >> >
> >> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <agri...@google.com>
> >> wrote:
> >> >
> >> >> I'd like to take a first step towards moving plugin JS into separate
> >> > repos
> >> >> by first moving them around within cordova-js.
> >> >>
> >> >> Here is my proposal:
> >> >>
> >> >> Current structure:
> >> >> lib/common/plugin/*.js
> >> >> lib/$PLATFORM/plugin/*.js
> >> >>
> >> >> New structure:
> >> >> plugin/$PLUGIN_NAME/js/common/*.js
> >> >> plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >> >>
> >> >> The require path will need to change. Going from:
> >> >> cordova.require('cordova/plugin/FileTransferError')
> >> >> To:
> >> >> cordova.require('plugin/file/FileTransferError')
> >> >>
> >> >>
> >> >> I'll obviously need to update the builder scripts accordingly. The
> idea
> >> >> here is that we:
> >> >> 1. "cordova plugin add" will copy files into a project's
> plugins
> >> >> directory
> >> >> 2. "cordova build ios" will use the cordova-js packager and
> pass
> >> > it
> >> >> the plugin/ directory to use
> >> >>
> >> >> This will not involve changing how we export modules onto namespaces
> in
> >> >> common.js / platform.js. That will come next though.
> >> >>
> >> >>
> >> >> The resulting structure will look like:
> >> >>
> >> >> plugin/accelerometer/js/common/Acceleration.js
> >> >> plugin/accelerometer/js/common/accelerometer.js
> >> >> plugin/battery/js/common/battery.js
> >> >> plugin/compass/js/common/Compass*.js
> >> >> plugin/contacts/js/common/Contact*.js
> >> >> plugin/device/js/common/device.js
> >> >> plugin/geolocation/js/common/Coordinates.js
> >> >> plugin/geolocation/js/common/Position*.js
> >> >> plugin/globalization/js/common/Globalization*.js
> >> >> plugin/inappbrowser/js/common/InAppBrowser.js
> >> >> plugin/logger/js/common/logger.js
> >> >> plugin/logger/js/common/console-via-logger.js
> >> >> plugin/media/js/common/Capture*.js
> >> >> plugin/media/js/common/ConfigurationData.js
> >> >> plugin/media/js/common/Media*.js
> >> >> plugin/network/js/common/Connection.js
> >> >> plugin/notification/js/common/notification.js
> >> >> plugin/camera/js/common/Camera*.js
> >> >> plugin/echo/js/common/echo.js
> >> >> plugin/file/js/common/Directory*.js
> >> >> plugin/file/js/common/Entry.js
> >> >> plugin/file/js/common/File*.js
> >> >> plugin/file/js/common/Flags.js
> >> >> plugin/file/js/common/LocalFileSystem.js
> >> >> plugin/file/js/common/Metadata.js
> >> >> plugin/file/js/common/ProgressEvent.js
> >> >> plugin/splashscreen/js/common/splashscreen.js
> >> >
> >>
> >
> >
>
--
@purplecabbage
risingj.com
