Again, thanks for the feedback guys!
> The original proposal said that pre-compiled "Can be an alternative (not
> replacement) to distributing plugins as source-code." so I don't think the
> original intent was for selling plugins.
Please, don't read too much into what I wrote. I just wanted to get this
suggestion out of my head before it was, once again, forgotten.
I think distributing a plugin without the source code is a compelling
option to some plugin developers. Commercial businesses may want to
interface with internal libraries that are not open sourced or even
distributed as a library. For example, maybe an Augmented Reality plugin
taps into algorithms that are the foundation of the AR company's business.
I'm more than happy to shelve this library suggestion and revisit it after
plugins have been exercised by Cordova users.
Michael
On Mon, Feb 25, 2013 at 10:01 AM, Michal Mocny <mmo...@chromium.org> wrote:
> The original proposal said that pre-compiled "Can be an alternative (not
> replacement) to distributing plugins as source-code." so I don't think the
> original intent was for selling plugins. Thats not to say that that isn't
> useful, but my understanding is that end goal of this particular thread is
> attaining app developer simplicity.
>
>
> On Mon, Feb 25, 2013 at 12:49 PM, Andrew Grieve <agri...@chromium.org
> >wrote:
>
> > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>
