If this only refers to the cli project level config, then I withdraw my objection.
However, consistency creates clarity. Maybe taking a step back, why do we have different config.xml files per platform anyway? Given that they are all following the same spec ( our modified widget spec ) shouldn't they all be capable of reading feature/param[@name="X"] and only applying the preferences they support? @purplecabbage risingj.com On Mon, Feb 17, 2014 at 12:55 PM, Axel Nennker <ignisvul...@gmail.com>wrote: > <projectdir>/config.xml vs. <platform>/config.xml > > <projectdir>/config.json could be used to generate e.g. > platforms/android/config.xml > or similar on platforms that need/prefer XML > > > Am 17.02.2014 20:33 schrieb "Jesse" <purplecabb...@gmail.com>: > > > > The config.xml file is currently read at launch on all platforms to > decide > > what the start-page is, any preferences that exist, and what features are > > allowed. > > This has deeper implications than just cli projects. > > > > @purplecabbage > > risingj.com > > > > > > On Mon, Feb 17, 2014 at 11:26 AM, Brian LeRoux <b...@brian.io> wrote: > > > > > this is at the project level (cli projects) not the platform level so I > > > think we're ok > > > > > > that said, this whole discussion reeks of bikeshed > > > > > > > > > On Mon, Feb 17, 2014 at 11:17 AM, Jesse <purplecabb...@gmail.com> > wrote: > > > > > > > FYI. Windows Phone SDK and Windows 8 'native' .net SDKs do NOT > provide a > > > > library to parse generic json objects, while reading XML is trivial. > > > > I could easily add the 6MB JSON.net [1] library to support this, but > I > > > have > > > > avoided every dependency I could in getting to this point, so I would > > > > rather not. I would likely have to write ~400 LOC to use the > > > > DataContractJsonSerializer to parse the file, which isn't a huge > deal, > > > but > > > > should be considered. I always strive to write as little code as > > > possible. > > > > > > > > Please keep in mind the 'native' implications of making the move to > .json > > > > only, and not just the convenience of inspecting, authoring, and > > > modifying > > > > the config file. > > > > > > > > > > > > > > > > [1] http://james.newtonking.com/json > > > > [2] > > > > > > > > > > > > > http://msdn.microsoft.com/en-us/library/system.runtime.serialization.json.datacontractjsonserializer(v=vs.110).aspx > > > > > > > > > > > > @purplecabbage > > > > risingj.com > > > > > > > > > > > > On Mon, Feb 17, 2014 at 8:34 AM, Josh Soref <jso...@blackberry.com> > > > wrote: > > > > > > > > > Jonathan wrote: > > > > > > It fits more naturally with some 'native' tools (e.g. android & > > > windows > > > > > 8). > > > > > > IDE's have better support for it. > > > > > > > > > > This is changing > > > > > > > > > > > > > > http://blogs.msdn.com/b/visualstudioalm/archive/2014/02/06/json-debugger-visualizer-in-visual-studio-2013.aspx > > > > > > > > > > > If you're developing only with css,js,html -> json makes more > sense > > > > > > > > > > > If you're developing using native tools (plugman flow) -> xml > makes > > > > more > > > > > sense > > > > > > > > > > Tools evolve. I don't see this as a particularly strong argument. > > > > > > > >
