cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: [plugins] Static or Dynamic Libraries
Date Sat, 23 Feb 2013 00:33:31 GMT
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 <bowserj@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
> <michael@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 <cmarcelk@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message