On Mon, Jan 14, 2013 at 4:04 PM, Gord Tanner <gtan...@gmail.com> wrote:
> Yes,
>
> BlackBerry is really 3 platforms in one. We used to have them as 3
> seperate platforms but was a headache for writing apps and ensuring that
> you had the right javascript file in the right place.
>
Just so I understand this, is it that blackberry has fat binaries? e.g. one
binary can be deployed to multiple platforms?
Otherwise, it's quite likely that cordova-cli will make the old
multi-platform headaches go away.
>
> Since I wrote most of the module stuff I agree I have abused it a little
> with some of the tricks of the trade we have in place with the build step.
>
> I would rather see us handle this via the exec bridge than including script
> files in the DOM (stay with me for a little bit).
>
> Not a final spec but an idea would be:
>
> var foo = require('cordova/plugin/foo')
>
> inside require we would realize we don't have foo preloaded in cordova.js
> and call exec>
>
> exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: "foo",
> platform: "ios"})
>
> where success would be something like:
>
> function (func) {
> cordova.define('cordova/plugin/foo', func);
> }
>
> Thoughts?
>
Gord, what's the motivation for this? Maybe that it addresses the having
alter <script> tags when adding/removing plugins?
You'd still need to deal with knowing which JS to include in your App
package (might be a bit bloated to include all JS for all platforms in all
apps)
It would mean making require() an async call (unless you use sync. XHRs),
and I think would have negative effects on performance.
>
>
> 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, ..)
> >
> >
> > > >
> > > > 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
> >
>
