cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Holmquist <lholm...@redhat.com>
Subject Re: new meta data for plugin.xml
Date Tue, 22 Oct 2013 00:29:11 GMT
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 <braden@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 <lholmqui@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 <mmocny@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 <iclelland@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 <lholmqui@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 <stevengill97@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.kadri@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 <
>>> stevengill97@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 <shazron@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.ercan@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
<
>>> mmocny@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
<
>>>>>>>> lholmqui@redhat.com
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> i was just thinking the same thing  :)
>>>>>>>>>>>>> On Oct 18, 2013, at 12:06 PM, Carlos
Santana <
>>>>>>>> csantana23@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 <
>>>>>>>>>> stevengill97@gmail.com
>>>>>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Yes I meant plugins.xml
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Oct 18, 2013, at 5:43
AM, Lucas Holmquist <
>>>>>>>>>> lholmqui@redhat.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Oct 17, 2013, at 7:54
PM, Steven Gill <
>>>>>>>>>> stevengill97@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
>>>>>>>>>>>>>> <csantana23@gmail.com>
>> 

Mime
View raw message