cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [plugins] Static or Dynamic Libraries
Date Fri, 22 Feb 2013 19:02:11 GMT
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 <framework> instead of a <source-file> in plugin.xml


On Fri, Feb 22, 2013 at 9:29 AM, Michael Brooks <michael@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message