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 <agri...@chromium.org>wrote: > On Fri, Feb 22, 2013 at 2:02 PM, Shazron <shaz...@gmail.com> 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 <framework> instead of a <source-file> 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
