Thanks Brian. It's interesting to hear the history.
Sent from my iPhone
> On Oct 21, 2013, at 7:45 PM, Brian LeRoux <b...@brian.io> wrote:
>
> Not so much an accident as very deliberate!
>
> When we started this is how you worked with JSON:
>
> var data = eval('"' + my_json_string + '"')
>
> We then had some fun w/ Crockford's JSON lib licensing. [1] Specifically
> IBM did not like the enforceability of "The Software shall be used for
> Good, not Evil." clause. Doug offered to rewrite it: "The Software shall be
> used for Good, not Evil, unless you are IBM." But surprisingly this was not
> enough. So, we wrote our own JSON lib. Yup. JavaScript was pretty awesome 5
> years ago.
>
>
> /me grumbles about lawn or something
>
>
> [1] http://www.json.org/license.html
>
>
>
> On Mon, Oct 21, 2013 at 7:41 AM, Braden Shepherdson
> <bra...@chromium.org>wrote:
>
>> I'd be happier if it were JSON, but it's not, and the XML doesn't cause
>> enough pain to be worth making the switch.
>>
>> Ian explained it accurately; it's mostly a historical accident that we're
>> using XML.
>>
>> Braden
>>
>>
>> On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist <lholm...@redhat.com
>>> wrote:
>>
>>> yea, this is understandable. wasn't really sure the reasoning, but it
>>> looks like diminishing returns here
>>>> On Oct 21, 2013, at 10:06 AM, Michal Mocny <mmo...@chromium.org> wrote:
>>>>
>>>> XML is also buying us a couple of small but nice features, such as
>>>> optionally wrapping tags with a <platform> tag or (potentially) a
>> <mode>
>>>> tag, etc. That functionality would not be expressed as cleanly with
>>> JSON,
>>>> so its not a pure win to move away from XML.
>>>>
>>>> Add to that the fact that we are already perceived to change stuff way
>>> too
>>>> often for no due cause, I just really don't see the value.
>>>>
>>>>
>>>>> On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland <iclell...@google.com>
>>>> wrote:
>>>>
>>>>> I suspect that it is because plugin.xml was derived (intellectually,
>> if
>>> not
>>>>> literally) from config.xml, which was an XML file because of the W3C
>>>>> Widgets spec, which we tried to adhere to.
>>>>>
>>>>> Whether that spec is still relevant (there doesn't seem to be a lot of
>>>>> vendor interest in it (speaking as an Apache member, *not* as a vendor
>>>>> representative)) is definitely up for debate. There probably are some
>>> gains
>>>>> to be made in switching to a JSON config format, given how much of the
>>>>> project is JavaScript these days, but it might not be worth all of the
>>> work
>>>>> it would take to do it.
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>> On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist <lholm...@redhat.com
>>>>>> wrote:
>>>>>
>>>>>> Perhaps this has been brought up before, but why are we using an xml
>>>>>> file? why not make it a json file.
>>>>>>
>>>>>> Plugman is written in node( js ) so why not have the plugin "config"
>>> file
>>>>>> in it's native format. This will probably save a bit of code since
>> the
>>>>> xml
>>>>>> is converted to an object to manipulate anyway.
>>>>>>
>>>>>>
>>>>>> i know this is a little off topic.
>>>>>>
>>>>>> thoughts?
>>>>>>
>>>>>> On Oct 18, 2013, at 5:31 PM, Steven Gill <stevengil...@gmail.com>
>>> wrote:
>>>>>>
>>>>>>> I have created an issue to keep track of the registry refactor.
>>>>>>> https://issues.apache.org/jira/browse/CB-5130
>>>>>>>
>>>>>>>
>>>>>>>> On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI <anis.ka...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I added some validation for plugin names (to follow
>>>>>>>> reverse-domain-name convention) a couple of weeks ago but there
>> needs
>>>>>>>> to be more of it for sure.
>>>>>>>>
>>>>>>>> On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill <
>>> stevengil...@gmail.com
>>>>>>
>>>>>>>> wrote:
>>>>>>>>> I have created an issue to track the meta tag addition.
>>>>>>>>> https://issues.apache.org/jira/browse/CB-5128
>>>>>>>>>
>>>>>>>>> I agree with doing validation with plugman during publish time. We
>>>>>> should
>>>>>>>>> decide soon which ones are going to be mandatory and which ones
>> will
>>>>> be
>>>>>>>>> optional. Probably update the plugin spec + our docs around
>> creating
>>>>>>>>> plugins as well.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Oct 18, 2013 at 11:54 AM, Shazron <shaz...@gmail.com>
>>> wrote:
>>>>>>>>>
>>>>>>>>>> Perhaps either plugman or the registry should do some validation,
>>>>> and
>>>>>>>> have
>>>>>>>>>> some "required" fields? I know that PhoneGap Build when you try
>> to
>>>>>>>> submit a
>>>>>>>>>> plugin they error out if you are missing some fields that they
>>>>>> require.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan <
>>>>>> gorkem.er...@gmail.com
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> +1 for adding metadata but should more of the metadata be
>>>>> compulsory?
>>>>>>>>>>>
>>>>>>>>>>> JBoss tools plugin discovery uses the cordova.io registry and
>>> some
>>>>>>>> of
>>>>>>>>>> the
>>>>>>>>>>> plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a
>>>>>>>> screenshot
>>>>>>>>>>> that shows how the case. http://snag.gy/J8rl6.jpg is a
>> screenshot
>>>>> of
>>>>>>>> a
>>>>>>>>>> few
>>>>>>>>>>> plugins that has most of its data. As you can see with the
>> missing
>>>>>>>>>>> descriptions etc. it is not possible to do an informed decision
>> on
>>>>>>>>>> whether
>>>>>>>>>>> to use a plugin or not. Although information such as keywords
>> does
>>>>>> not
>>>>>>>>>> seem
>>>>>>>>>>> like important it becomes quite useful when you are trying to
>> find
>>>>> a
>>>>>>>>>>> certain plugin.
>>>>>>>>>>> --
>>>>>>>>>>> Gorkem
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny <
>>> mmo...@chromium.org
>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +1 to repo / issue / website / docs etc metadata
>>>>>>>>>>>>
>>>>>>>>>>>> -1 *for now* to dependencies at specific versions, and testing
>>>>>>>> related
>>>>>>>>>>>> changes like <mode>, just because its not clear what the right
>>>>>>>> solution
>>>>>>>>>>> to
>>>>>>>>>>>> these problems is. We do need to address it, but those topics
>>>>> will
>>>>>>>>>>> likely
>>>>>>>>>>>> move to separate discussions.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist <
>>>>>>>> lholm...@redhat.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> i was just thinking the same thing :)
>>>>>>>>>>>>> On Oct 18, 2013, at 12:06 PM, Carlos Santana <
>>>>>>>> csantan...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> plugin.xml metadata is looking more and more like a
>>> package.json
>>>>>>>>>>> (i.e.
>>>>>>>>>>>>> npm)
>>>>>>>>>>>>>> ;-p
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill <
>>>>>>>>>> stevengil...@gmail.com
>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes I meant plugins.xml
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist <
>>>>>>>>>> lholm...@redhat.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Oct 17, 2013, at 7:54 PM, Steven Gill <
>>>>>>>>>> stevengil...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So looks like want to to start including more data on
>>>>>>>>>>>>>>>>> http://plugins.cordova.io.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Repo tag -> points to repo where plugin lives
>>>>>>>>>>>>>>>>> Issue tag -> points to issue tracker (with component for
>>>>>>>> jira)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Testing related (can get discussed more in testing thread
>>>>>>>>>>>>>>>>> Mode tag -> to differentiate between testing mode and
>> normal
>>>>>>>>>> mode
>>>>>>>>>>>>>>>>> JS module tag for test module
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Dependency related
>>>>>>>>>>>>>>>>> adding version number to dependency tags so they don't
>> just
>>>>>>>> grab
>>>>>>>>>>>>> latest
>>>>>>>>>>>>>>>>> always. Multiple approaches were discussed and this
>>>>>>>> discussion
>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>> probably happen in a new thread.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thoughts on above? Suggestions for other meta data we
>> should
>>>>>>>>>> look
>>>>>>>>>>>> into
>>>>>>>>>>>>>>>>> adding to config.xml?
>>>>>>>>>>>>>>>> did you mean plugin.xml?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Carlos Santana
>>>>>>>>>>>>>> <csantan...@gmail.com>
>>
