incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <alu...@gmail.com>
Subject Re: plugin format: why plugin.xml instead of plugin.json ?
Date Thu, 11 Oct 2012 17:52:59 GMT
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