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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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. >>>>> >>>
