almost certain we could align down to a single configuration for everything safely extending package.json (and treating ./platform/whatever/[...]/www/config.xml as compile targets
also almost certain this is not actually important! On Mon, Feb 17, 2014 at 1:13 PM, Jesse <purplecabb...@gmail.com> wrote: > 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. > > > > > > > > > > > >
