You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Mike Reinstein <re...@gmail.com> on 2012/10/11 12:20:38 UTC
plugin format: why plugin.xml instead of plugin.json ?
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
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Mike Reinstein <re...@gmail.com>.
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 <al...@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 <al...@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 <pu...@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 <an...@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 <fi...@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" <re...@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
> >>
> >
> >
>
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Andrew Lunny <al...@gmail.com>.
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 <al...@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 <pu...@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 <an...@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 <fi...@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" <re...@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
>>
>
>
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Andrew Lunny <al...@gmail.com>.
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 <pu...@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 <an...@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 <fi...@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" <re...@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
>
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Filip Maj <fi...@adobe.com>.
I like that approach best. Gives us flexibility for the discovery bits
moving forward will maintaining the the work put in thus far for config.xml
On 10/11/12 10:13 AM, "Jesse" <pu...@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 <an...@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 <fi...@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" <re...@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
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Jesse <pu...@gmail.com>.
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 <an...@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 <fi...@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" <re...@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
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Anis KADRI <an...@gmail.com>.
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 <fi...@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" <re...@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
> >
> >
>
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Brian LeRoux <b...@brian.io>.
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 <fi...@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" <re...@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
>
>
Re: plugin format: why plugin.xml instead of plugin.json ?
Posted by Filip Maj <fi...@adobe.com>.
Probably no reason other than "because Andrew wrote it and that's what he
chose"
On 10/11/12 3:20 AM, "Mike Reinstein" <re...@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