agreed widget is dead tho other specs are emergent solving the same problems:
- mozilla fxos apps manifest.webapp - chrome packaged apps manifest.json - sys apps at the w3c is...discussing this so I'm not sure if our efforts are best spent solving the problem w/ a new format though that would be consistent w/ XKCD https://xkcd.com/927/ On Fri, Feb 14, 2014 at 7:55 AM, Jonathan Bond-Caron < jbo...@gdesolutions.com> wrote: > On Thu Feb 13 10:49 AM, Braden Shepherdson wrote: > > > > except for the persistent question of what we're gaining with all these > changes. > > Like the JSON config files idea, I'd be happy if we were already in that > world. But > > the transition is sufficiently painful that switching doesn't feel worth > it; we don't > > gain enough to justify the pain. > > > > However! That only applies to the configuration file reshuffling. If we > really can > > refactor Plugman's flows to have reversible transactions, that would > definitely > > make me happy. But I don't think we should conflate the config changes > and that > > refactoring - they're independent. We would need to expand the metadata > > tracked by plugman, of course, but that's not the same as moving all the > > configuration. > > > > Agree that some plugman refactoring isn't related to config changes. > But some work would involve converting plugin.xml --> project.json > (installed metadata) > > I'd argue we gain a lot by doing this, there's so much IO going on to keep > the installed plugin.xml files around and reading those files. > In comparison to a single project.json, that's a big benefit. > > If there's going to be code written to map xml to json, it makes sense to > work on 1-1 mapping of xml & json config files in 1 swoop. > > Added a section on preferences around xml or json: > https://wiki.apache.org/cordova/config/cordova.xml > > Ultimately the bit I think is important is dropping the widget spec, it's > counter-productive. > >
