On Mon, Jan 14, 2013 at 3:41 PM, Jesse <purplecabb...@gmail.com> wrote:
> 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, ..)
>
Where do you see it overwriting things? I see a few clobbers / merges in
their platform.js files, but it looks like they re-use the bulk of the
common code. The main difference seems to be that they implement exec() via
a require() call, and the native code on iOS/Android maps to .js code in
their plugin directory.
What would the plugin-specific build system look like for our core plugins?
When you say that they will have pre-built JS, is that just using the
cordova packager as well? Or do you think some other functionality is
required?
>
>
> > >
> > > 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
>
> Are you sure? I just tested this in mobile-spec on iOS, and cordova.plugin
is undefined.
>
>
>
> > >
> > > 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
>
