Re: [plugins] Static or Dynamic Libraries
>
> For Android plugin developers if they want to keep their source hidden they
> could provide only the class that extends from CordovaPlugin in source form
> and have it call their code in a provided jar file. Just trying to think of
> a simple way for folks to provide "for pay" plugins.
Good to know!
On Tue, Mar 5, 2013 at 11:40 AM, Simon MacDonald
wrote:
> For Android plugin developers if they want to keep their source hidden they
> could provide only the class that extends from CordovaPlugin in source form
> and have it call their code in a provided jar file. Just trying to think of
> a simple way for folks to provide "for pay" plugins.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Mon, Mar 4, 2013 at 5:41 PM, Michael Brooks >wrote:
>
> > 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
> > 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 > > >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 >
> > > > wrote:
> > > > > > >
> > > > > > > > Hey
> > > > > > > >
> > > > > > > > I'm definitely a fan of pre-c
Re: [plugins] Static or Dynamic Libraries
For Android plugin developers if they want to keep their source hidden they
could provide only the class that extends from CordovaPlugin in source form
and have it call their code in a provided jar file. Just trying to think of
a simple way for folks to provide "for pay" plugins.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Mar 4, 2013 at 5:41 PM, Michael Brooks wrote:
> 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
> 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 > >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
> > > 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
> > > > > > >
Re: [plugins] Static or Dynamic Libraries
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 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 >wrote:
>
> > On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson > >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
> > 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
> > > > > > wrote:
> > > > > > > Great responses everyone. We've now got a decent o
Re: [plugins] Static or Dynamic Libraries
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 wrote:
> On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson >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
> 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
> > > > > 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
Re: [plugins] Static or Dynamic Libraries
On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson 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 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
> > > > 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>
> >
Re: [plugins] Static or Dynamic Libraries
I agree with all that Marcel said, and I think most of the points he
outlined are well under way. So, I vote we just revisit this once those
are done and we have some time to ingest the changes, and see if we still
have a use case for this.
For the example of 2 year old plugin, it seems unlikely to me that a 2 year
old unmaintained precompiled plugin is going to work well, anyway (I don't
think we have that sort of api consistency, yet).
Fot the plugin's marketplace example, this does sound potentially
compelling. Is anyone specifically requesting this already? Or, do we
want to build it, so that they will come?
-Michal
On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson 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.
>
> 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 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
> > > > 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 lon
Re: [plugins] Static or Dynamic Libraries
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.
Braden
On Sat, Feb 23, 2013 at 10:07 PM, Simon MacDonald 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 >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 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
> > > 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
> > > 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] u
Re: [plugins] Static or Dynamic Libraries
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 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 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 > > 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 > > 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 some
Re: [plugins] Static or Dynamic Libraries
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 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 > 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 > 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 >
Re: [plugins] Static or Dynamic Libraries
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 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 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
Re: [plugins] Static or Dynamic Libraries
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 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
Re: [plugins] Static or Dynamic Libraries
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
Re: [plugins] Static or Dynamic Libraries
I think compiled distribution should be an option, that we support. In WP7+8 one of the new project options includes all Cordova native code in a compiled dll. The dll is duplicated for each project ( not truly a shared dynamic library ), but it does allows for a simplified user project structure. To me, if you are distributing a compiled plugin, it would be a release version only, so I don't think debug/release is an issue, but the multiple architecture could be. I believe there are project settings you can use to link to the correct version though. This is also the way that most nuget packaged libraries are distributed. ie, you can use my code, but you can't see my code. On Fri, Feb 22, 2013 at 11:23 AM, Andrew Grieve wrote: > On Fri, Feb 22, 2013 at 2:02 PM, Shazron wrote: > > > Feasibility > > --- > > For iOS, plugins can be static libraries, that is no problem. You cannot > > use dynamic libraries in iOS (the .frameworks you see used are > essentially > > static libs in a different packaging). Assets should be .bundle packages > > (essentially folders with the .bundle suffix). So you will have the .a, > > header files, and any .bundle assets. > > > > Problems > > -- > > Authors have to make sure that the .a lib is a fat binary that includes > all > > architectures. If not, a user cannot test on the Simulator for example, > if > > the i386 architecture wasn't included. I suppose plugman or some tool can > > check for this by using the 'lipo -info [lib]' command. > > > > This is the biggest trouble we've had when trying this approach before. > There's also debug vs release. > It does seem to be the way many people are releasing their SDKs though. > e.g. > > https://developers.google.com/maps/documentation/ios/start#adding_the_google_maps_sdk_for_ios_to_your_project > > > > > > > > Benefits > > > > Plugin marketplace, selling of plugins without releasing the source. > > Plugman already supports .a plugins indirectly, you would just add the > > plugin as a instead of a in plugin.xml > > > > > > On Fri, Feb 22, 2013 at 9:29 AM, Michael Brooks < > mich...@michaelbrooks.ca > > >wrote: > > > > > Hi all, > > > > > > I'd like to pick your brain around the feasibility of plugins existing > as > > > static or dynamic libraries. > > > > > > I had this idea a few years ago, when we first started discussing > > plugins. > > > At the time, it was > > > possible on BlackBerry and, with some work, possible on Android and > iOS. > > > However, a lot > > > has changed in the last few years, so I'd like to revisit the topic. > > > > > > Overview: > > > > > > - A plugin developer would compile their plugin as a static or dynamic > > > library. > > > - A plugin developer would publish their plugin as the library. > > > - An app developer would install the static or dynamic library. > > > > > > Benefits: > > > > > > - The plugin is only compiled by the author who distributes it. > > > - For complex plugins, this may help avoid compile-time errors > around > > > dependencies. > > > - The plugin may be able to bundle some of its assets, simplifying the > > > installation process. > > > - Can be an alternative (not replacement) to distributing plugins as > > > source-code. > > > > > > Questions: > > > > > > - For each platform, how feasible is this? > > > - What problems (or other benefits) would exist with plugins as > > libraries? > > > > > > Thanks! > > > Michael > > > > > > -- @purplecabbage risingj.com
Re: [plugins] Static or Dynamic Libraries
On Fri, Feb 22, 2013 at 2:02 PM, Shazron wrote: > Feasibility > --- > For iOS, plugins can be static libraries, that is no problem. You cannot > use dynamic libraries in iOS (the .frameworks you see used are essentially > static libs in a different packaging). Assets should be .bundle packages > (essentially folders with the .bundle suffix). So you will have the .a, > header files, and any .bundle assets. > > Problems > -- > Authors have to make sure that the .a lib is a fat binary that includes all > architectures. If not, a user cannot test on the Simulator for example, if > the i386 architecture wasn't included. I suppose plugman or some tool can > check for this by using the 'lipo -info [lib]' command. > This is the biggest trouble we've had when trying this approach before. There's also debug vs release. It does seem to be the way many people are releasing their SDKs though. e.g. https://developers.google.com/maps/documentation/ios/start#adding_the_google_maps_sdk_for_ios_to_your_project > > > Benefits > > Plugin marketplace, selling of plugins without releasing the source. > Plugman already supports .a plugins indirectly, you would just add the > plugin as a instead of a in plugin.xml > > > On Fri, Feb 22, 2013 at 9:29 AM, Michael Brooks >wrote: > > > Hi all, > > > > I'd like to pick your brain around the feasibility of plugins existing as > > static or dynamic libraries. > > > > I had this idea a few years ago, when we first started discussing > plugins. > > At the time, it was > > possible on BlackBerry and, with some work, possible on Android and iOS. > > However, a lot > > has changed in the last few years, so I'd like to revisit the topic. > > > > Overview: > > > > - A plugin developer would compile their plugin as a static or dynamic > > library. > > - A plugin developer would publish their plugin as the library. > > - An app developer would install the static or dynamic library. > > > > Benefits: > > > > - The plugin is only compiled by the author who distributes it. > > - For complex plugins, this may help avoid compile-time errors around > > dependencies. > > - The plugin may be able to bundle some of its assets, simplifying the > > installation process. > > - Can be an alternative (not replacement) to distributing plugins as > > source-code. > > > > Questions: > > > > - For each platform, how feasible is this? > > - What problems (or other benefits) would exist with plugins as > libraries? > > > > Thanks! > > Michael > > >
Re: [plugins] Static or Dynamic Libraries
Feasibility --- For iOS, plugins can be static libraries, that is no problem. You cannot use dynamic libraries in iOS (the .frameworks you see used are essentially static libs in a different packaging). Assets should be .bundle packages (essentially folders with the .bundle suffix). So you will have the .a, header files, and any .bundle assets. Problems -- Authors have to make sure that the .a lib is a fat binary that includes all architectures. If not, a user cannot test on the Simulator for example, if the i386 architecture wasn't included. I suppose plugman or some tool can check for this by using the 'lipo -info [lib]' command. Benefits Plugin marketplace, selling of plugins without releasing the source. Plugman already supports .a plugins indirectly, you would just add the plugin as a instead of a in plugin.xml On Fri, Feb 22, 2013 at 9:29 AM, Michael Brooks wrote: > Hi all, > > I'd like to pick your brain around the feasibility of plugins existing as > static or dynamic libraries. > > I had this idea a few years ago, when we first started discussing plugins. > At the time, it was > possible on BlackBerry and, with some work, possible on Android and iOS. > However, a lot > has changed in the last few years, so I'd like to revisit the topic. > > Overview: > > - A plugin developer would compile their plugin as a static or dynamic > library. > - A plugin developer would publish their plugin as the library. > - An app developer would install the static or dynamic library. > > Benefits: > > - The plugin is only compiled by the author who distributes it. > - For complex plugins, this may help avoid compile-time errors around > dependencies. > - The plugin may be able to bundle some of its assets, simplifying the > installation process. > - Can be an alternative (not replacement) to distributing plugins as > source-code. > > Questions: > > - For each platform, how feasible is this? > - What problems (or other benefits) would exist with plugins as libraries? > > Thanks! > Michael >
Re: [plugins] Static or Dynamic Libraries
Hi Michael, Thanks for raising this. We went through this exact question on BlackBerry 10 WebWorks SDK last year and eventually made the decision to pre-compile plugins. >> - For each platform, how feasible is this? BlackBerry 10 is unique in its nature of plugins, as in the Framework (non-plugin code) itself is all JavaScript and does not need to be compiled but the plugins might contain native (C/C++) code. This means that even though the developer does not need to compile the framework they would have to compile the plugins. So the choice for BlackBerry 10 was obvious, the plugins are indeed compiled into libraries that are then loaded at runtime. This obviously provides the benefit of simplicity to the end user, who does not need to compile the native code. On older BlackBerry and Playbook platforms this is also feasible as library loading is supported by both Java and ActionScript, although it might be slow on Java (will need prototyping) >> - What problems (or other benefits) would exist with plugins as >>libraries? We also added a feature where we only load the library when an API is used the first time. This reduces memory consumption at launch of the application reducing startup time for the application. Obviously if your API is time sensitive it should be loaded at startup. I imagine this is a major benefit that can probably be achieved by other platforms as well. BlackBerry 10 WebWorks SDK received a lot of Kudos from our developers for reducing dependencies and time when building their application. I can imagine similar benefits of decreasing build time (might be minimal though) can be achieved on other platforms even though reducing build time dependencies might not be feasible for all platforms. We are yet to observe any negative impact of this approach. Obviously these benefits are automatically carried over to the BlackBerry 10 implementation of Cordova as well. Nukul Bhasin Team Lead, BlackBerry WebWorks Tel: 289 261 5574 Research in Motion Limited On 2/22/13 12:29 PM, "Michael Brooks" wrote: >Hi all, > >I'd like to pick your brain around the feasibility of plugins existing as >static or dynamic libraries. > >I had this idea a few years ago, when we first started discussing plugins. >At the time, it was >possible on BlackBerry and, with some work, possible on Android and iOS. >However, a lot >has changed in the last few years, so I'd like to revisit the topic. > >Overview: > >- A plugin developer would compile their plugin as a static or dynamic >library. >- A plugin developer would publish their plugin as the library. >- An app developer would install the static or dynamic library. > >Benefits: > >- The plugin is only compiled by the author who distributes it. >- For complex plugins, this may help avoid compile-time errors around >dependencies. >- The plugin may be able to bundle some of its assets, simplifying the >installation process. >- Can be an alternative (not replacement) to distributing plugins as >source-code. > >Questions: > >- For each platform, how feasible is this? >- What problems (or other benefits) would exist with plugins as libraries? > >Thanks! >Michael - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
