Based on the variety of feedback, it sounds like the manifest really makes sense to keep in XML, because:
- JSON lacks newline support which makes XML graft/prune hard to express. - I thought about using something like jsonML but that means having another weird translation step for the XML fragments - I thought about having the XML fragments in other files (/fragments folder in plugin) but this is messy because it puts the package config in multiple places - I really dislike the idea of using a translation step to maintain json and xml representing the same thing. Loads of opportunity for desyncing. -Mike On Thu, Oct 11, 2012 at 1:52 PM, Andrew Lunny <alu...@gmail.com> wrote: > FWIW, here's a gist showing three possible formats for the same task > (specify that an activity element should be added to the AndroidManifest) > https://gist.github.com/3874222 > > activity-a.json converts the XML data structure to a JSON data structure. > Obviously you lose the distinction between attributes and child elements. > It's also difficult to express empty child nodes (see the intent-filter in > that example). And you then need to specify a process for converting > between the JSON representation and the XML representation, which is one > more thing for a tool to fuck up. > > activity-b.json is closer to what the XML format does, but requires: > a) escaping all quotes (I guess you could use single quotes, but then you > end up with a manifest that has a mix of single quotes and double quotes > for attributes) > b) removing all newlines. In a simple case like this (the line is 175 > characters) it's possibly manageable, but larger examples quickly become > untenable. > > activity.xml is what we have, and seems demonstrably more readable, > expressive, and easier to maintain that either of the alternatives. There > is a valid concern with this format and namespacing (see > https://github.com/alunny/cordova-plugin-spec/issues/4), but even if we > took that on board, having newlines and comments would keep the a big > readability win. > > If anyone has another JSON format to suggest, I'm all ears. > > Andrew > > On 11 October 2012 10:34, Andrew Lunny <alu...@gmail.com> wrote: > > > Because every platform we target (and every config file we have to > output) > > uses XML, and it's easier to interoperate. > > > > > > On 11 October 2012 10:13, Jesse <purplecabb...@gmail.com> wrote: > > > >> Can use both ... .json for npm-like package discovery and .xml for > >> install-time configuration. > >> > >> On the wp7 pluginstall, I liked the xml format because I essentially > >> just defined an xml fragment that gets appended to the output project > >> file ( also an xml file ) > >> > >> > >> > >> > >> On Thu, Oct 11, 2012 at 10:02 AM, Anis KADRI <anis.ka...@gmail.com> > >> wrote: > >> > I think we should stick to it for now. I am totally in favor of using > >> JSON > >> > in the future but right now I would like to see more plugins use this > >> XML > >> > format. > >> > > >> > On Thu, Oct 11, 2012 at 9:51 AM, Brian LeRoux <b...@brian.io> wrote: > >> > > >> >> ya the past is irrelevant. since we're moving to npm for the pkg mgmt > >> we > >> >> should probably move to an extension of package.json > >> >> > >> >> instead of clobbering andrew's work (and creating work for him) we > >> should > >> >> have a light module in-between that is responsible for marshaling > >> between > >> >> the formats. > >> >> > >> >> this stuff is decidedly not hard but certainly not interesting or > fun. > >> >> > >> >> On Thu, Oct 11, 2012 at 9:41 AM, Filip Maj <f...@adobe.com> wrote: > >> >> > >> >> > Probably no reason other than "because Andrew wrote it and that's > >> what he > >> >> > chose" > >> >> > > >> >> > On 10/11/12 3:20 AM, "Mike Reinstein" <reinstein.m...@gmail.com> > >> wrote: > >> >> > > >> >> > >If this is an old discussion/argument I'm sorry for re-hashing > >> this. I'm > >> >> > >wondering why express the plugin manifest in xml, when its managed > >> in > >> >> > >node/javascript which handles json natively. There doesn't seem to > >> be > >> >> any > >> >> > >significant nesting or complex XML within the doc thus far. > >> Intentional > >> >> > >design decision? Any info on this would be enlightening and > helpful. > >> >> > > > >> >> > >thanks, > >> >> > > > >> >> > >-Mike > >> >> > > >> >> > > >> >> > >> > >> > >> > >> -- > >> @purplecabbage > >> risingj.com > >> > > > > >
