incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: plugin format: why plugin.xml instead of plugin.json ?
Date Thu, 11 Oct 2012 19:21:21 GMT
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 <alunny@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 <alunny@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 <purplecabbage@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.kadri@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 <fil@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.mike@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
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message