Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of anis.kadri@gmail.com
 designates 209.85.192.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADVgkyNGx-cgC8x2SxiB4RLNeP3n92EeJXLrt3Rzed6SuvORqg@mail.gmail.com>
References: 
 <CANpVHHxLwdaXhVrfGmznt7WLVL7UK39hQUTZ2ZQN1Y3uiGHMjg@mail.gmail.com>
	<CE1C3287.23301%fil@adobe.com>
	<CANpVHHyS37O==7sQg5dqk0cLpmgcjg8wxhUAW+8+oymKJVdO7w@mail.gmail.com>
	<CADVgkyNGx-cgC8x2SxiB4RLNeP3n92EeJXLrt3Rzed6SuvORqg@mail.gmail.com>
Date: Mon, 29 Jul 2013 16:41:33 -0700
Message-ID: 
 <CANpVHHxzKh_tEtQx1TiEt0sbiCOO-9TgWyD1dQk6t3n7e0WBaA@mail.gmail.com>
Subject: Re: Plugin / Platform mismatch problems
From: Anis KADRI <anis.kadri@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

I spoke with @dshaw about this and told him why it was (currently) not
an option for Cordova.

Specifically (un)install actions and dependency management are
different. It seems like a a lot of overhead to get npm to do what
plugman (un)install does.

Everything else is pretty much the same and moving from plugin.xml to
package.json won't hurt us I don't think. I guess we wouldn't be able
to do XSLTs to validate documents but...other than that it would be a
logical move.

The other thing too is that npm is mainly for nodejs and/or javascript
packages and getting Cordova plugins in there can make search and
discovery harder. There are currently 36,472 NPMs as of this writing.
The counter-argument to this is that there are npm modules that use
native codes to execute. Some of them even require some third-party
interpreters (Ruby, Python, etc...).

On Mon, Jul 29, 2013 at 4:28 PM, Brian LeRoux <b@brian.io> wrote:
> I have a parallel conversation rolling w/ the node guys and they're
> hoping to convince us to move everything to the npm registry itself.
> (Or at least be compatible to do so.)
>
> I think this is a worthwhile goal but it does mean:
>
> - plugin.xml gets either deprecated for package.json or we continue
> tool that impedance mismatch
> - install on the npm side needs to learn about cordova (yes issac is
> open to this!)
>
> Did I miss anything Anis?
>
> Thoughts [larger group]?
>
>
>
> On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
>> Agree.
>> For the last point. There is a <keywords> tag added to the spec to
>> facilitate search. Has to be added by plugin author.
>> I am going to drop the current names for the registry and republish
>> them with the new convention. Unless anyone has any objections. We'll
>> implement that prefixing right after.
>>
>> On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj <fil@adobe.com> wrote:
>>> I think what would work is:
>>>
>>> - use ids to uniquely identify
>>> - prepending org.apache.cordova.core or w/e our core plugin namespace is
>>> as a fallback attempt to match makes sense
>>> - finally, for discovery/searching, we should do searches vs a plugin's
>>> <description> field and do our best to enforce good descriptions on
>>> plugins being submitted to the apache cordova registry
>>>
>>> On 7/29/13 1:13 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>>
>>>>Right but npm registry uses JSON not XML. I think prefixing core
>>>>plugins when no package name is provided is a good idea.
>>>>
>>>>On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard <cmarcelk@gmail.com> wrote:
>>>>> That could be accomplished with XSLT. And XPath has basic query
>>>>>capability. James Jong and I have skills in those.
>>>>>
>>>>> On Jul 26, 2013, at 2:19 PM, Filip Maj <fil@adobe.com> wrote:
>>>>>
>>>>>> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml
>>>>>> fields to json fields?
>>>>>>
>>>>>> On 7/26/13 10:27 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>>>>>
>>>>>>> I think XML is not a query friendly language. I suggest we add an
>>>>>>> engine field initially and then add fields as we need them. I suspect
>>>>>>> we won't be needing the bulk of plugin.xml in the registry. I have to
>>>>>>> experiment with custom fields still but it seems possible. I will
>>>>>>> report back sometime today.
>>>>>
>>>