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 >
