You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Mike Reinstein <re...@gmail.com> on 2012/10/01 22:59:24 UTC
plugin analysis
hey gang,
i've gone through all of the plugins in
https://github.com/phonegap/phonegap-plugins and put together a basic
comparison grid to provide some visibility:
https://docs.google.com/spreadsheet/ccc?key=0Al813Y70ZNWbdC0zRFduOEY2M0tjZWYxOVVUbmVFRGc
Can anyone help with this? Tracking 92 plugins X 6 platforms is more than I
can handle on my own. :) Things that could be improved upon:
- contributors for each plugin are unknown
- popularity of plugins is unclear because the git stars is for the
whole repo, not individual plugins
- last updated is incomplete, and a rough estimate
- maybe there are other plugins not listed in phonegap-plugins repo that
should be added to this list
- probably should link to each project
- the "no" answer in each cell should be changed. it's not clear if a
plugin is missing because its only relevant for a given platform, (e.g.,
mapkit plugin doesnt make sense for Qt platform) or because it hasnt been
implemented
This is publicly editable to make collaboration easy. Goes without saying
but if you decide to contribute to this please dont trash/abuse it. :)
Any feedback would be really helpful on this. thanks!
-Mike
Re: plugin analysis
Posted by Filip Maj <fi...@adobe.com>.
Sweet thx
On 10/2/12 11:28 AM, "Brian LeRoux" <b...@brian.io> wrote:
>we spoke at nodecamp on just this (end of aug) so I'm fairly certain
>its safe but I'll confirm next week at jsconfeu
>
>On Tue, Oct 2, 2012 at 8:17 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>>>> - 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.
>>>
>>>Sure it does. engine attribute in package.json (but will require a
>>>custom couch view which can be authored rather quickly).
>>
>> For the record isaacs is discussing potentially removing that attrib
>>
>> https://groups.google.com/forum/#!topic/nodejs/_ZggTOJQ2Rk
>>
Re: plugin analysis
Posted by Brian LeRoux <b...@brian.io>.
we spoke at nodecamp on just this (end of aug) so I'm fairly certain
its safe but I'll confirm next week at jsconfeu
On Tue, Oct 2, 2012 at 8:17 PM, Filip Maj <fi...@adobe.com> wrote:
>
>>> - 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.
>>
>>Sure it does. engine attribute in package.json (but will require a
>>custom couch view which can be authored rather quickly).
>
> For the record isaacs is discussing potentially removing that attrib
>
> https://groups.google.com/forum/#!topic/nodejs/_ZggTOJQ2Rk
>
Re: plugin analysis
Posted by Michal Mocny <mm...@chromium.org>.
He's been answering my direct emails quite quickly (pinged him regarding
some notification work he had done).
On Tue, Oct 2, 2012 at 5:01 PM, Filip Maj <fi...@adobe.com> wrote:
> Max also hangs out on #phonegap on irc.freenode.net fairly consistently if
> you wanna chat him up
>
> On 10/2/12 12:34 PM, "Mike Reinstein" <re...@gmail.com> wrote:
>
> >haha, nice. Yeah, I actually spent a large portion of this week reading
> >npm's source. isaacs did a really nice job on it. npm's package.json lists
> >a number of module dependencies that will be very helpful for us as well
> >me
> >thinks.
> >
> >-Mike
> >
> >On Tue, Oct 2, 2012 at 3:28 PM, Andrew Lunny <al...@gmail.com> wrote:
> >
> >> Mike: get in contact with @maxogden - I think he did some work with Fil
> >>on
> >> this stuff, and he knows NPM inside out. Unfortunately, he's too cool
> >>for
> >> Apache mailing lists.
> >>
> >> On 2 October 2012 12:10, Mike Reinstein <re...@gmail.com>
> >>wrote:
> >>
> >> > Okay cool, sounds reasonable. I will try to hhack something up this
> >> week; I
> >> > have a few ideas in mind for this. :)
> >> >
> >> > onward!
> >> >
> >> > -Mike
> >> >
> >> > On Tue, Oct 2, 2012 at 2:53 PM, Brian LeRoux <b...@brian.io> wrote:
> >> >
> >> > > > Maybe I'm wrong but after reading
> >>https://npmjs.org/doc/json.htmlI'm
> >> > > > under the impression this is solely for specifying the required
> >> > > version(s)
> >> > > > of node to use the npm package.
> >> > >
> >> > > correct. we'd extend it with support for something like.
> >> > >
> >> > > { "engines" : { "cordova" : ">=2.2.0" } }
> >> > >
> >> > >
> >> > >
> >> > > > The problem is before allowing someone to register a plugin...
> >> > >
> >> > > ya. npm registry is unique by pkg name; no collision fear. other
> >> > > checks can be added or maybe built w/ that tool you're talking about
> >> > > for sure.
> >> > >
> >> >
> >>
>
>
Re: plugin analysis
Posted by Filip Maj <fi...@adobe.com>.
Max also hangs out on #phonegap on irc.freenode.net fairly consistently if
you wanna chat him up
On 10/2/12 12:34 PM, "Mike Reinstein" <re...@gmail.com> wrote:
>haha, nice. Yeah, I actually spent a large portion of this week reading
>npm's source. isaacs did a really nice job on it. npm's package.json lists
>a number of module dependencies that will be very helpful for us as well
>me
>thinks.
>
>-Mike
>
>On Tue, Oct 2, 2012 at 3:28 PM, Andrew Lunny <al...@gmail.com> wrote:
>
>> Mike: get in contact with @maxogden - I think he did some work with Fil
>>on
>> this stuff, and he knows NPM inside out. Unfortunately, he's too cool
>>for
>> Apache mailing lists.
>>
>> On 2 October 2012 12:10, Mike Reinstein <re...@gmail.com>
>>wrote:
>>
>> > Okay cool, sounds reasonable. I will try to hhack something up this
>> week; I
>> > have a few ideas in mind for this. :)
>> >
>> > onward!
>> >
>> > -Mike
>> >
>> > On Tue, Oct 2, 2012 at 2:53 PM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> > > > Maybe I'm wrong but after reading
>>https://npmjs.org/doc/json.htmlI'm
>> > > > under the impression this is solely for specifying the required
>> > > version(s)
>> > > > of node to use the npm package.
>> > >
>> > > correct. we'd extend it with support for something like.
>> > >
>> > > { "engines" : { "cordova" : ">=2.2.0" } }
>> > >
>> > >
>> > >
>> > > > The problem is before allowing someone to register a plugin...
>> > >
>> > > ya. npm registry is unique by pkg name; no collision fear. other
>> > > checks can be added or maybe built w/ that tool you're talking about
>> > > for sure.
>> > >
>> >
>>
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
haha, nice. Yeah, I actually spent a large portion of this week reading
npm's source. isaacs did a really nice job on it. npm's package.json lists
a number of module dependencies that will be very helpful for us as well me
thinks.
-Mike
On Tue, Oct 2, 2012 at 3:28 PM, Andrew Lunny <al...@gmail.com> wrote:
> Mike: get in contact with @maxogden - I think he did some work with Fil on
> this stuff, and he knows NPM inside out. Unfortunately, he's too cool for
> Apache mailing lists.
>
> On 2 October 2012 12:10, Mike Reinstein <re...@gmail.com> wrote:
>
> > Okay cool, sounds reasonable. I will try to hhack something up this
> week; I
> > have a few ideas in mind for this. :)
> >
> > onward!
> >
> > -Mike
> >
> > On Tue, Oct 2, 2012 at 2:53 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > > Maybe I'm wrong but after reading https://npmjs.org/doc/json.htmlI'm
> > > > under the impression this is solely for specifying the required
> > > version(s)
> > > > of node to use the npm package.
> > >
> > > correct. we'd extend it with support for something like.
> > >
> > > { "engines" : { "cordova" : ">=2.2.0" } }
> > >
> > >
> > >
> > > > The problem is before allowing someone to register a plugin...
> > >
> > > ya. npm registry is unique by pkg name; no collision fear. other
> > > checks can be added or maybe built w/ that tool you're talking about
> > > for sure.
> > >
> >
>
Re: plugin analysis
Posted by Andrew Lunny <al...@gmail.com>.
Mike: get in contact with @maxogden - I think he did some work with Fil on
this stuff, and he knows NPM inside out. Unfortunately, he's too cool for
Apache mailing lists.
On 2 October 2012 12:10, Mike Reinstein <re...@gmail.com> wrote:
> Okay cool, sounds reasonable. I will try to hhack something up this week; I
> have a few ideas in mind for this. :)
>
> onward!
>
> -Mike
>
> On Tue, Oct 2, 2012 at 2:53 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > > Maybe I'm wrong but after reading https://npmjs.org/doc/json.html I'm
> > > under the impression this is solely for specifying the required
> > version(s)
> > > of node to use the npm package.
> >
> > correct. we'd extend it with support for something like.
> >
> > { "engines" : { "cordova" : ">=2.2.0" } }
> >
> >
> >
> > > The problem is before allowing someone to register a plugin...
> >
> > ya. npm registry is unique by pkg name; no collision fear. other
> > checks can be added or maybe built w/ that tool you're talking about
> > for sure.
> >
>
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
Okay cool, sounds reasonable. I will try to hhack something up this week; I
have a few ideas in mind for this. :)
onward!
-Mike
On Tue, Oct 2, 2012 at 2:53 PM, Brian LeRoux <b...@brian.io> wrote:
> > Maybe I'm wrong but after reading https://npmjs.org/doc/json.html I'm
> > under the impression this is solely for specifying the required
> version(s)
> > of node to use the npm package.
>
> correct. we'd extend it with support for something like.
>
> { "engines" : { "cordova" : ">=2.2.0" } }
>
>
>
> > The problem is before allowing someone to register a plugin...
>
> ya. npm registry is unique by pkg name; no collision fear. other
> checks can be added or maybe built w/ that tool you're talking about
> for sure.
>
Re: plugin analysis
Posted by Brian LeRoux <b...@brian.io>.
> Maybe I'm wrong but after reading https://npmjs.org/doc/json.html I'm
> under the impression this is solely for specifying the required version(s)
> of node to use the npm package.
correct. we'd extend it with support for something like.
{ "engines" : { "cordova" : ">=2.2.0" } }
> The problem is before allowing someone to register a plugin...
ya. npm registry is unique by pkg name; no collision fear. other
checks can be added or maybe built w/ that tool you're talking about
for sure.
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
Hey Brian,
> engine attribute in package.json
Maybe I'm wrong but after reading https://npmjs.org/doc/json.html I'm
under the impression this is solely for specifying the required version(s)
of node to use the npm package.
> I do not understand the problem
The problem is before allowing someone to register a plugin, we want to
perform certain checks on the server side that prevent things from blowing
up or corrupting the repo. One very easy thing to check is that the package
identifier a plugin author declares is not collding. I should not be able
to package com.alunny.foo if it's already used by another package.
> (Lets not solve ones we do not yet have yet
I agree that we should not try to predict every problem that could come up
and solve it up front. I also think that some issues have a nice balance
between being able to check, and being easy to do that them worth doing.
Simple things like verifying plugin.xml is a valid xml doc, that package
names dont collide, etc are very easy to do, and are important to repo
integrity.
On Tue, Oct 2, 2012 at 2:13 PM, Brian LeRoux <b...@brian.io> wrote:
> > - 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.
>
> Sure it does. engine attribute in package.json (but will require a
> custom couch view which can be authored rather quickly).
>
> > - 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.
>
> I do not understand the problem but I'm certain once there is code we
> could implement a solution. (Lets not solve ones we do not yet have
> too much!)
>
> > - 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.
>
> ya its cool, I've talked to the node guys about it. we'll likely run a
> separate federated registry in the future. in issac's own words, 'npm
> is a commons for js'
>
>
> > Having a little discovery portal like npmjs.org that is
> > specific to our community would be huge.
>
> thats the vision breaux
>
Re: plugin analysis
Posted by Filip Maj <fi...@adobe.com>.
>> - 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.
>
>Sure it does. engine attribute in package.json (but will require a
>custom couch view which can be authored rather quickly).
For the record isaacs is discussing potentially removing that attrib
https://groups.google.com/forum/#!topic/nodejs/_ZggTOJQ2Rk
Re: plugin analysis
Posted by Brian LeRoux <b...@brian.io>.
> - 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.
Sure it does. engine attribute in package.json (but will require a
custom couch view which can be authored rather quickly).
> - 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.
I do not understand the problem but I'm certain once there is code we
could implement a solution. (Lets not solve ones we do not yet have
too much!)
> - 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.
ya its cool, I've talked to the node guys about it. we'll likely run a
separate federated registry in the future. in issac's own words, 'npm
is a commons for js'
> Having a little discovery portal like npmjs.org that is
> specific to our community would be huge.
thats the vision breaux
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
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 <al...@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 <an...@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 <ka...@gmail.com>
> wrote:
> > >
> > > > On Mon, Oct 1, 2012 at 4:29 PM, Jesse <pu...@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
> > > >
> > >
> >
>
Re: plugin analysis
Posted by Brian LeRoux <b...@brian.io>.
Echo plugin from the docs comes to mind.
On Tue, Oct 2, 2012 at 7:21 PM, Andrew Lunny <al...@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 <an...@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 <ka...@gmail.com> wrote:
>> >
>> > > On Mon, Oct 1, 2012 at 4:29 PM, Jesse <pu...@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
>> > >
>> >
>>
Re: plugin analysis
Posted by Andrew Lunny <al...@gmail.com>.
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 <an...@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 <ka...@gmail.com> wrote:
> >
> > > On Mon, Oct 1, 2012 at 4:29 PM, Jesse <pu...@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
> > >
> >
>
Re: plugin analysis
Posted by Anis KADRI <an...@gmail.com>.
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 <re...@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 <ka...@gmail.com> wrote:
>
> > On Mon, Oct 1, 2012 at 4:29 PM, Jesse <pu...@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
> >
>
Re: plugin analysis
Posted by Brian LeRoux <b...@brian.io>.
we're moving to npm ...eventually.
On Mon, Oct 1, 2012 at 11:41 PM, Mike Reinstein
<re...@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 <ka...@gmail.com> wrote:
>
>> On Mon, Oct 1, 2012 at 4:29 PM, Jesse <pu...@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
>>
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
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 <ka...@gmail.com> wrote:
> On Mon, Oct 1, 2012 at 4:29 PM, Jesse <pu...@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
>
Re: plugin analysis
Posted by Bryan Bishop <ka...@gmail.com>.
On Mon, Oct 1, 2012 at 4:29 PM, Jesse <pu...@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
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
Hey Jesse,
I'd like to talk about the plugin discovery mechanism that you mentioned.
I've been working on setting up a couchdb instance locally, and pulling a
bunch of code from npm to come up with a solution for this, including a
site front end. I think I recall Fil mentioning that you were in the
planning stages for this. Would like to chat more so we can coordinate
better, ya dig?
-Mike
On Mon, Oct 1, 2012 at 5:29 PM, Jesse <pu...@gmail.com> wrote:
> A few reasons for the existing structure :
>
> - the repo was singular to help users discover plugins
> - moving to individual repos would destroy commit histories for
> plugins ( so we should minimize the number of times we move them )
> - the repo itself has grown far beyond what was expected, it was meant
> to be a 'for now' solution to be re-addressed when we had solidified a
> better plugin installation/discovery mechanism ( in progress, but
> overdue based on this repo ... )
>
> Cheers,
> Jesse
> @purplecabbage
>
> On Mon, Oct 1, 2012 at 2:23 PM, Mike Reinstein <re...@gmail.com>
> wrote:
> > @Bryan: I believe each plugin basicallly does have its own repo, and this
> > is mirrored in our "official" repo.
> >
> > @Don: great, thanks for adding your plugin info!
> >
> >
> >
> > On Mon, Oct 1, 2012 at 5:19 PM, Bryan Bishop <ka...@gmail.com> wrote:
> >
> >> On Mon, Oct 1, 2012 at 3:59 PM, Mike Reinstein <
> reinstein.mike@gmail.com
> >> >wrote:
> >>
> >> > - popularity of plugins is unclear because the git stars is for the
> >> > whole repo, not individual plugins
> >> >
> >>
> >> Is there any reason each plugin shouldn't have its own separate repo?
> >>
> >> - Bryan
> >> http://heybryan.org/
> >> 1 512 203 0507
> >>
>
>
>
> --
> @purplecabbage
> risingj.com
>
Re: plugin analysis
Posted by Jesse <pu...@gmail.com>.
A few reasons for the existing structure :
- the repo was singular to help users discover plugins
- moving to individual repos would destroy commit histories for
plugins ( so we should minimize the number of times we move them )
- the repo itself has grown far beyond what was expected, it was meant
to be a 'for now' solution to be re-addressed when we had solidified a
better plugin installation/discovery mechanism ( in progress, but
overdue based on this repo ... )
Cheers,
Jesse
@purplecabbage
On Mon, Oct 1, 2012 at 2:23 PM, Mike Reinstein <re...@gmail.com> wrote:
> @Bryan: I believe each plugin basicallly does have its own repo, and this
> is mirrored in our "official" repo.
>
> @Don: great, thanks for adding your plugin info!
>
>
>
> On Mon, Oct 1, 2012 at 5:19 PM, Bryan Bishop <ka...@gmail.com> wrote:
>
>> On Mon, Oct 1, 2012 at 3:59 PM, Mike Reinstein <reinstein.mike@gmail.com
>> >wrote:
>>
>> > - popularity of plugins is unclear because the git stars is for the
>> > whole repo, not individual plugins
>> >
>>
>> Is there any reason each plugin shouldn't have its own separate repo?
>>
>> - Bryan
>> http://heybryan.org/
>> 1 512 203 0507
>>
--
@purplecabbage
risingj.com
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
@Bryan: I believe each plugin basicallly does have its own repo, and this
is mirrored in our "official" repo.
@Don: great, thanks for adding your plugin info!
On Mon, Oct 1, 2012 at 5:19 PM, Bryan Bishop <ka...@gmail.com> wrote:
> On Mon, Oct 1, 2012 at 3:59 PM, Mike Reinstein <reinstein.mike@gmail.com
> >wrote:
>
> > - popularity of plugins is unclear because the git stars is for the
> > whole repo, not individual plugins
> >
>
> Is there any reason each plugin shouldn't have its own separate repo?
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
Re: plugin analysis
Posted by Bryan Bishop <ka...@gmail.com>.
On Mon, Oct 1, 2012 at 3:59 PM, Mike Reinstein <re...@gmail.com>wrote:
> - popularity of plugins is unclear because the git stars is for the
> whole repo, not individual plugins
>
Is there any reason each plugin shouldn't have its own separate repo?
- Bryan
http://heybryan.org/
1 512 203 0507
Re: plugin analysis
Posted by Mike Reinstein <re...@gmail.com>.
Hi Fil,
Thanks for the list, these do seem like very important plugins. All the
ones that are already in the official phonegap-plugins repo are tracked
(BarcodeScanner, fb) but the others aren't. Do you have links? I can add
them to the list.
-Mike
On Tue, Oct 2, 2012 at 1:56 PM, Filip Maj <fi...@adobe.com> wrote:
> From the PhoneGap Build team guys (Andrew Lunny et al), this may be
> relevant to the search, Mike.
>
> http://community.phonegap.com/nitobi/topics/_phonegap_build_future_plugin_s
> upport
>
>
> On 10/1/12 1:59 PM, "Mike Reinstein" <re...@gmail.com> wrote:
>
> >hey gang,
> >
> >i've gone through all of the plugins in
> >https://github.com/phonegap/phonegap-plugins and put together a basic
> >comparison grid to provide some visibility:
> >
> >
> https://docs.google.com/spreadsheet/ccc?key=0Al813Y70ZNWbdC0zRFduOEY2M0tjZ
> >WYxOVVUbmVFRGc
> >
> >Can anyone help with this? Tracking 92 plugins X 6 platforms is more than
> >I
> >can handle on my own. :) Things that could be improved upon:
> >
> > - contributors for each plugin are unknown
> > - popularity of plugins is unclear because the git stars is for the
> > whole repo, not individual plugins
> > - last updated is incomplete, and a rough estimate
> > - maybe there are other plugins not listed in phonegap-plugins repo
> >that
> > should be added to this list
> > - probably should link to each project
> > - the "no" answer in each cell should be changed. it's not clear if a
> > plugin is missing because its only relevant for a given platform,
> >(e.g.,
> > mapkit plugin doesnt make sense for Qt platform) or because it hasnt
> >been
> > implemented
> >
> >
> >This is publicly editable to make collaboration easy. Goes without saying
> >but if you decide to contribute to this please dont trash/abuse it. :)
> >
> >Any feedback would be really helpful on this. thanks!
> >
> >-Mike
>
>
Re: plugin analysis
Posted by Filip Maj <fi...@adobe.com>.
>From the PhoneGap Build team guys (Andrew Lunny et al), this may be
relevant to the search, Mike.
http://community.phonegap.com/nitobi/topics/_phonegap_build_future_plugin_s
upport
On 10/1/12 1:59 PM, "Mike Reinstein" <re...@gmail.com> wrote:
>hey gang,
>
>i've gone through all of the plugins in
>https://github.com/phonegap/phonegap-plugins and put together a basic
>comparison grid to provide some visibility:
>
>https://docs.google.com/spreadsheet/ccc?key=0Al813Y70ZNWbdC0zRFduOEY2M0tjZ
>WYxOVVUbmVFRGc
>
>Can anyone help with this? Tracking 92 plugins X 6 platforms is more than
>I
>can handle on my own. :) Things that could be improved upon:
>
> - contributors for each plugin are unknown
> - popularity of plugins is unclear because the git stars is for the
> whole repo, not individual plugins
> - last updated is incomplete, and a rough estimate
> - maybe there are other plugins not listed in phonegap-plugins repo
>that
> should be added to this list
> - probably should link to each project
> - the "no" answer in each cell should be changed. it's not clear if a
> plugin is missing because its only relevant for a given platform,
>(e.g.,
> mapkit plugin doesnt make sense for Qt platform) or because it hasnt
>been
> implemented
>
>
>This is publicly editable to make collaboration easy. Goes without saying
>but if you decide to contribute to this please dont trash/abuse it. :)
>
>Any feedback would be really helpful on this. thanks!
>
>-Mike