A few points questions: @Brian: I've heard a few people mention the idea of using npm as the repo for plugins. It could work, but there are a few thoughts/issues:
- Cordova plugins depend on specific versions of the cordova library, and specific versions of xcode, android build tools, and other SDKs. npm doesnt provide a way to declare those external plugin dependencies, or query by them. - one thing that would really be helpful in the future is to have the ability to set up rules at the repo publishing point. For example, preventing someone from publishing a new plugin that re-uses and existing package name (com.alunny.foo) and doing basic sanity checks that are specific to our plugin format. Using npm makes this a lot harder. - npm is intended as a dev tool and package manager for node based apps/libs. We'd be overloading it's intended behavior by throwing in a bunch of plugins that are relevant only to the Cordova platform. - this last point isnt really a technical problem, but more an opinion. After spending some time on the irc channel for phonegap, reading various forums, and being on the user side of cordova, it seems that most people are horribly confused about how to author, discover, use, and share plugins. Having a little discovery portal like npmjs.org that is specific to our community would be huge. @Andrew:I agree on all points. Plugin development is the bigger problem. I do think that further work on the plugin format will help solve this. I envision something like 'cordova plugin init' which could step through creating a skeleton package, which would stub out all the platform directories. This coupled with good plugin authoring documentation, and a repo to publish plugins against solves the development and distribution aspects. Your plugin tool with a little more work solves the installation issue. On Tue, Oct 2, 2012 at 1:21 PM, Andrew Lunny <alu...@gmail.com> wrote: > My two cents: the biggest issue is not distribution (which can take care of > itself until it's a bottleneck) or installation (which we've done a lot of > work on) but plugin development. > > There's no way to write a plugin outside of the context of a specific app > you're developing; and most plugins are extracted from an existing app. > This means cross-platform concerns aren't taken into consideration (it may > not be the same person implementing each port, for instance), API > development isn't really standardized, and bugs/issues/updates aren't > always timely. > > Thinking out loud here, but it might be useful to have a PluginApp > template/harness that anyone could use/install as a harness and environment > for writing cross-platform plugins, that enforces some of these things and > encourages good practices. Not sure exactly what that would look like - it > would probably become clear after we throw out a couple crappy attempts. > > Andrew > > On 2 October 2012 09:43, Anis KADRI <anis.ka...@gmail.com> wrote: > > > I believe there will be plugins that are not cross platform because there > > are platform specific features that might need to be supported. However, > I > > believe that when a plugin can be cross platform (such as ChildBrowser) > > than it should be and the javascript implementation should be the same no > > matter what the platform is. > > > > On Mon, Oct 1, 2012 at 2:41 PM, Mike Reinstein <reinstein.m...@gmail.com > > >wrote: > > > > > IMO the biggest problem is plugin fragmentation across platforms...what > > we > > > really need to fix is getting a single plugin with support for 1 or > more > > > platforms into a place. It will keep related code together, and will > > > hopefully promote a unified js API as much as possible...I cringe to > > think > > > what the different APIs for these related plugins might look like. > Maybe > > > for ios its one API, for android another, etc. These fears may be > > unfounded > > > as I havent started diving into each one yet. > > > > > > -Mike > > > > > > On Mon, Oct 1, 2012 at 5:38 PM, Bryan Bishop <kanz...@gmail.com> > wrote: > > > > > > > On Mon, Oct 1, 2012 at 4:29 PM, Jesse <purplecabb...@gmail.com> > wrote: > > > > > > > > > - moving to individual repos would destroy commit histories for > > > > > plugins ( so we should minimize the number of times we move them ) > > > > > > > > > > > > > Not true at all! There is excellent support in git for surgically > > > > extracting the commit history of a subfolder and all of its source > > code. > > > I > > > > do this all the time when I recover dying things from the hands of > > > > oblivion. It involves a call to "git filter-branch". > > > > > > > > uh off the top of my head, this looks close: > > > > > > > > > > > > > > http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository > > > > > > > > Anyway, I don't have a strong opinion either way, just don't write > off > > > the > > > > option for technical reasons :-). > > > > > > > > - Bryan > > > > http://heybryan.org/ > > > > 1 512 203 0507 > > > > > > > > > >
