Hey Andrew, Nice work. A few of my thoughts in-line.
>* the manifest is in XML because so are most of the config formats we're >dealing with (AndroidManifest, App-Info.plist, config.xml). Having an XML >manifest makes it easy to include, say, extra permission tags to be >included on Android, with XPath selectors to say where they should go in >the target document Gord and I have a similar TODO in the cordova-js project, to figure out some kind of packaging format for plugins. It's relevant to both of our projects. Gord was thinking a package.json-like format; perhaps we could consolidate requirements from both of our projects to come up with a spec that satisfies both of our needs? I like how the native side of plugins are figured out in your XML format, as well as the integration into the native manifest formats. >* in most cases, it would be preferable for JavaScript files to be >cross-platform compatible; however, the format is flexible enough to allow >`asset` nodes to be children of `platform` nodes, and thus >platform-specific Can you explain the two <asset> nodes in your example plugins.xml ? What is the difference between the two elements? Lines 8-9. >... >A couple of open issues: >* the current format doesn't have a mechanism for specifying that one >plugin depends on another, which will be necessary >* there's no way to specify a dependency on an external library - for >example, a separate framework on iOS. I will investigate options as I >begin >work on the iOS side of the code. Could we use what mechanisms already exist in package.json to figure this out? Maybe add an extension to this? It'd be nice to be able to feature phonegap plugins and other tools in NPM, and it seems we're going the route of node anyways for our CLI stuff.
