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. >>>> >>
