On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson <bra...@chromium.org>wrote:
> I'm working on our prototype for automatic installation of Javascript from
> plugins in cordova-cli. We already have installation for native code and
> non-JS www assets. I don't see anything to be gained from precompiled
> libraries, since a user of Cordova already has the device SDK in place and
> is using either our scripts (cordova build, bin/emulate, etc.) or
> Eclipse/Xcode/etc. to build the deployable application.
>
> Switching to libraries loses us transparency for bugfixes ("make this
> change in some/plugin/File.java and see if that fixes your bug") and error
> messages, and it's not like we've got closed-source products we want to
> make sure people can't read.
>
Yep, this is certainly a trade-off with this approach. I don't think we're
suggesting moving any of the core plugins to be pre-compiled, but just that
this will enable people to sell plugins without giving away their source
code.
>
> Braden
>
>
> On Sat, Feb 23, 2013 at 10:07 PM, Simon MacDonald <
> simon.macdon...@gmail.com
> > wrote:
>
> > The other issue with jars on Android is they will be unable to refer to
> > anything in the res folder. That's basically why Android library projects
> > exist as conventional jars just don't cut it. Luckily since most Cordova
> > plugins will do their UI in HTML the likelihood of the plugin needing to
> > access the res folder is very low.
> >
> >
> > Simon Mac Donald
> > http://hi.im/simonmacdonald
> >
> >
> > On Fri, Feb 22, 2013 at 7:33 PM, Michael Brooks <
> mich...@michaelbrooks.ca
> > >wrote:
> >
> > > Sweet, thanks for the Android input Joe!
> > >
> > > It's awesome to see such detailed responses for Android, BlackBerry,
> iOS,
> > > and Windows!
> > >
> > > I suppose we can proceed as Marcel suggestion? Create JIRA issue, link
> to
> > > this thread, but keep our vision forward by finishing source-code
> > > distributed plugins.
> > >
> > > Michael
> > >
> > > On Fri, Feb 22, 2013 at 4:23 PM, Joe Bowser <bows...@gmail.com> wrote:
> > >
> > > > Hey
> > > >
> > > > I'm definitely a fan of pre-compiled libraries for plugins. The main
> > > > reason I like JARs instead of Java files is because of the following:
> > > >
> > > > * Cleaner projects
> > > > * Installation is extremely easy for non-Activity plugins (drop in
> the
> > > > libs directory)
> > > >
> > > > The downsides on Android:
> > > >
> > > > * You can't verify a JAR - Have to trust that the JAR isn't sketchy,
> > > > signatures can mitigate this, but not eliminate it
> > > > * JARs can't transport assets, assets would have to be transported
> > > > separately
> > > >
> > > > Overall, if you sign the JARs and allow for a mechanism for our users
> > > > to check the signature of the JAR, I'm cool with this approach. We
> > > > should remember that our users aren't the type of people who will
> > > > check a Java file to make sure the plugin does what it says it does,
> > > > and it would be nice to be able to have a tool to give them some
> > > > assurance that the plugin does only what they think it does.
> > > >
> > > > Joe
> > > >
> > > >
> > > > On Fri, Feb 22, 2013 at 1:30 PM, Michael Brooks
> > > > <mich...@michaelbrooks.ca> wrote:
> > > > > Great responses everyone. We've now got a decent overall of the iOS
> > and
> > > > WP
> > > > > landscape, not to mention use-cases of other projects such Google
> > Maps.
> > > > >
> > > > > tl;dr: IMHO, those three things listed above is where we should put
> > our
> > > > >> effort to make plugins easier, then see where that gets us. I
> think
> > it
> > > > will
> > > > >> drive us the furthest forward. Then go back an reevaluate whether
> or
> > > > not to
> > > > >> provide precompiled libs to see if it truly makes life easier for
> > the
> > > > user,
> > > > >> or if it complicates life for the user.
> > > > >
> > > > >
> > > > > Marcel, this is the feedback that I was hoping to see! Thanks a
> bunch
> > > for
> > > > > the analysis.
> > > > >
> > > > > The project is always driven by what gives ours users the most
> value.
> > > So,
> > > > > it makes sense to not lose sight of our goal - offering plugins to
> > > users.
> > > > > If the first phase is source-code only, then so be it.
> > > > >
> > > > > The intention of packaging plugins as libraries is entirely around
> > > making
> > > > > the users' life less painful. I was reminded of this problem last
> > > night,
> > > > > when I had to compile a 2 year old OS X library because the
> developer
> > > did
> > > > > not publish the .framework. Unsurprisingly, it failed to build
> > because
> > > > > Xcode no longer bundles the necessary libraries. Similarly, if I
> > needed
> > > > to
> > > > > a use a JPG or MP3 library, I would not want to include the source
> > code
> > > > in
> > > > > my project simply because it takes too long to compile (assume it
> > does
> > > > > compile).
> > > > >
> > > > > Michael
> > > > >
> > > > > On Fri, Feb 22, 2013 at 12:38 PM, Marcel Kinard <
> cmarc...@gmail.com>
> > > > wrote:
> > > > >
> > > > >> So if I back up for a moment and look at the bigger picture, it
> > looks
> > > > like
> > > > >> what you are going for is to make it easier for Cordova users to
> > pick
> > > up
> > > > >> plugins, either base ones or third-party ones. There are many ways
> > to
> > > do
> > > > >> that, providing precompiled code is one way.
> > > > >>
> > > > >> If I were to step into the shoes of a relatively new Cordova user
> > who
> > > > >> wanted to pick up a plugin for my app, I don't think the
> compilation
> > > is
> > > > >> difficult enough to warrant some workaround such as providing
> > > > libraries. My
> > > > >> [admitedly, limited] understanding is that as a Cordova user I
> > always
> > > > need
> > > > >> to use the device SDK to build my app. Therefore the compiler is
> > right
> > > > >> there and it's not difficult to invoke (i.e., iOS always needs
> > > > compilation).
> > > > >>
> > > > >> While still in the shoes of that Cordova user, what appears to be
> > more
> > > > >> challenging in that role is figuring out what files are needed,
> > where
> > > to
> > > > >> put them, and what to edit (i.e., config.xml). Basically, getting
> > the
> > > > >> environment and content setup for the SDK to run against. After
> > that,
> > > > >> running the SDK/compiler is easy. So for this difficulty, the
> kinds
> > of
> > > > >> helps could include:
> > > > >> - docs: overall on how to install/remove plugins, and
> > plugin-specific
> > > > docs
> > > > >> on their specific requirements/quirks
> > > > >> - tooling: a CLI (i.e., plugman) that could make it as easy as npm
> > > > >> - verification: help me as a user understand if the plugin is in
> > there
> > > > >> correctly, (i.e., smoke test or something like 'rpm -V')
> > > > >>
> > > > >> tl;dr: IMHO, those three things listed above is where we should
> put
> > > our
> > > > >> effort to make plugins easier, then see where that gets us. I
> think
> > it
> > > > will
> > > > >> drive us the furthest forward. Then go back an reevaluate whether
> or
> > > > not to
> > > > >> provide precompiled libs to see if it truly makes life easier for
> > the
> > > > user,
> > > > >> or if it complicates life for the user.
> > > > >>
> > > > >> The library idea is neat, it ought be captured in Jira while these
> > > other
> > > > >> things are worked on first.
> > > > >>
> > > > >> -- Marcel Kinard
> > > >
> > >
> >
>
