> > 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 <[email protected]>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 <[email protected] > >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 <[email protected]> > > 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 <[email protected] > > > >wrote: > > > > > > > On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson < > > [email protected] > > > > >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 < > > > > > [email protected] > > > > > > 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 < > > > > > [email protected] > > > > > > >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 <[email protected] > > > > > > 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 > > > > > > > > <[email protected]> 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 < > > > > > [email protected]> > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
