incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: plugin analysis
Date Tue, 02 Oct 2012 17:59:51 GMT
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 <alunny@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.kadri@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.mike@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 <kanzure@gmail.com>
> wrote:
> > >
> > > > On Mon, Oct 1, 2012 at 4:29 PM, Jesse <purplecabbage@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
> > > >
> > >
> >
>

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