I like the <param name="registry"> idea!
The main thing I don't like about <feature>, is that it already means
something different in platform config.xml:
<feature name="LocalStorage">
<param name="ios-package" value="CDVLocalStorage" />
</feature>
This means that when JS makes an exec() for "LocalStorage", route it
to "CDVLocalStorage". JS-only plugins don't inject <feature>, and
<feature> does not contain plugin IDs. If a plugin has multiple exec()
targets, then it *must* inject multiple <feature> tags.
<dependency> is much closer, but the meaning is not as clear in
config.xml (e.g. apps depend on platforms as well).
So, how about using <cdv:plugin>? Name is quite clear :).
On Wed, Apr 23, 2014 at 12:35 AM, purplecabbage <purplecabb...@gmail.com> wrote:
> I think consistency with input and output config.xml files makes more sense
> than consistency with plugin.xml. So +1 <feature/>
>
> Sent from my iPhone
>
>> On Apr 22, 2014, at 8:06 PM, Gorkem Ercan <gorkem.er...@gmail.com> wrote:
>>
>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <agri...@chromium.org> wrote:
>>>
>>> Anis - Gorkem wants <feature> since it works with his IDE. *Why* do
>>> you prefer <feature>?
>> Just to be clear I am not trying to push for <feature> because it works on
>> the JBoss/Eclipse IDE now. I do not mind ripping it apart and implementing
>> a new editor if there is a good benefit. However I favor <feature> because
>> it allows validation and content assist due to its XSD (I think we have
>> discussed about this earlier) which is probably the only benefit of the xml
>> markup on a configuration file these days.
>>
>> If we use dependency for defining the plugins to be restored it does not
>> mean that <feature> magically disappears. It is still used by the platform
>> runtimes and therefore the CLI generated config.xml files. I guess that
>> would mean we still need to keep the documentation etc for it around.
>>
>> Also one thing that I have noticed when implementing the restore for
>> plugins because all the information is given as <param>s under feature it
>> is very easily extendible. For instance if someday we want to support
>> enterprise plugin registries, we could just add <param name="registry"
>> value="http://registry.acme.corp"; /> and use the value on the
>> implementation. Same could be done to dependency by adding another
>> attribute which would break the validations etc.
>>
>>
>>
>>>> On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI <anis.ka...@gmail.com> wrote:
>>>> I prefer <feature>.
>>>>
>>>>
>>>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <kam...@google.com>
>>>> wrote:
>>>>
>>>>> I prefer the <dependency> syntax. It's shorter, more intuitive and
>>>>> consistent with plugin.xml. I don't see much value in _partial_
>>> compliance
>>>>> with the w3c spec.
>>>>>
>>>>>
>>>>> On Tue, Apr 22, 2014 at 1:31 PM, Michal Mocny <mmo...@google.com>
>>> wrote:
>>>>>
>>>>>> Gorkem is adding awesome feature to restore plugins/platforms your app
>>>>>> depends on. There is some debate on the correct syntax to use in the
>>>>>> config.xml file: do we use (a) plugin.xml style <dependency> tags, or
>>> (b)
>>>>>> w3c widget spec <feature> tags?
>>>>>>
>>>>>> Gorkem votes (b), arguing that using widget spec helps his tools with
>>>>>> editing config.xml (existing gui editor, I assume?), and has
>>> implemented
>>>>> a
>>>>>> PR for it (https://github.com/apache/cordova-cli/pull/165).
>>>>>>
>>>>>> I vote (a), arguing that we already don't match widget spec, and
>>> already
>>>>>> have established syntax for for specifying plugin urls & versions in
>>>>>> plugin.xml (with docs and examples), and its better for our CLI
>>>>>> implementation to use existing plugin deps handlers.
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>> Background: read full thread titled "[GitHub] cordova-cli pull
>>> request:
>>>>>> CB-6469"
>>>
