Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of mmocny@google.com designates
 209.85.214.42 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CABiQX1W_AsSa3U881LiBxs2PTh3ZuX05DQeRew+niNLSa2XLrg@mail.gmail.com>
References: 
 <CAP7NMPp4U+Sixfa+rM_szSb_niK07K0u6PYiSAf984d1H4AsEA@mail.gmail.com>
	<CAE6O_-ZCVzD-E6M3zADOyoTwzx9u+UenKr8uUt8+MJHUc+z_tA@mail.gmail.com>
	<CABiQX1X+D++nvtFJLUpouO6AxP8dNvGWrK6E-8W5xW0wJ_fRbw@mail.gmail.com>
	<CAKP6k2t_dVbR1yW1yJUZT+MRWUUUXvyxK1Rorc2J8qBr7x9ijw@mail.gmail.com>
	<232E544B-C1DA-4E67-BA3C-632DED530398@gmail.com>
	<CAP7NMPrwB_1pUGur6xyAibke-khGDtp9MPfSCXJgprXPC7wPjQ@mail.gmail.com>
	<CAOBL_k5KNibR=S4rdZw1Wt9ogMtwV8TEup=XN3OsYBwqZqaxOQ@mail.gmail.com>
	<CAP7NMPqzemY79JUnOwPtRk_k51gvCcBJxteGaXHq1ZJua2Qmqw@mail.gmail.com>
	<CAM1AYQB_it=ufzd5=RSYZMXT4tcG4Ku6LHLWUx_obK-ghDLYmA@mail.gmail.com>
	<CAMk5LLmARmW7Ej4i0YuEhhgf6=Go=nEmVDZSR806RzuL94jzUQ@mail.gmail.com>
	<CABiQX1W_AsSa3U881LiBxs2PTh3ZuX05DQeRew+niNLSa2XLrg@mail.gmail.com>
Date: Mon, 25 Feb 2013 13:01:53 -0500
Message-ID: 
 <CAEeF2TdrLG7cJs9YFxkH9qVGXS5Nn1GoNfje9PDtUcdh9BeA-Q@mail.gmail.com>
Subject: Re: [plugins] Static or Dynamic Libraries
From: Michal Mocny <mmocny@chromium.org>
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=0015174488a205808304d69056d5

--0015174488a205808304d69056d5
Content-Type: text/plain; charset=ISO-8859-1

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 <agrieve@chromium.org>wrote:

> On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson <braden@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.macdonald@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 <
> > michael@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 <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
> > > > >
> > > >
> > >
> >
>

--0015174488a205808304d69056d5--