Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of mmocny@google.com designates
 209.85.220.178 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: <5357e819.aa1f450a.1c68.7e18@mx.google.com>
References: 
 <CAEeF2Tfn_+Hxdq6a2zrEvQ8YGEt6pc7woGTJjSKr=nDSO8h-Mg@mail.gmail.com>
 <CA+GVa3Zkb7gkZX35WbfcSnZQYphGb5G5HB1kJQ0BK+BqP5aG9g@mail.gmail.com>
 <CANpVHHyD=jrfe_A5DPqPFhPJc1wFRpTHtJ3PhEMh1Ujjt8jQcw@mail.gmail.com>
 <CABiQX1XEyTiTcHgmO_+aZ0PE85uD8aEzTeu9cWmTS3ytXOhyjA@mail.gmail.com>
 <CA+X37cm-DYTXAJQVFFAKvAWHYnjFSpVNfcBz2FoCaNK3WYdEHQ@mail.gmail.com>
 <5357431c.6ae7440a.7618.2cb1@mx.google.com>
 <CABiQX1W+-2EBptoy6mm5kdZVQTDvRtUhZzyFJUZ18mVJPzdCxQ@mail.gmail.com>
 <CAEeF2TczaDQf=J-zT1cqMkZRgAoiCd=b5a9rGLfnLfp-x0PTvw@mail.gmail.com>
 <5357e819.aa1f450a.1c68.7e18@mx.google.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Wed, 23 Apr 2014 13:26:22 -0400
Message-ID: 
 <CAEeF2TdF2w=jv9evQPcJi1tYPV0m5b+vYTomhJcq22SwaHpr4w@mail.gmail.com>
Subject: Re: Looking for input on syntax to use for specifying plugin deps in
 config.xml
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b3a95784ed06e04f7b909d2

--047d7b3a95784ed06e04f7b909d2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Gorkem has an initial implementation posted here:
https://github.com/apache/cordova-cli/pull/165 -- but its missing a change
previously discussed to support explicit "cordova restore" instead of
auto-restore-on-prepare.  He also made us a video:
https://www.youtube.com/watch?v=3Dbc60WAQdOjE

The syntax for deps in that patch currently uses <feature> tags and looks
like this:

<feature name=3D=E2=80=9CConsole=E2=80=9D>
  <param name=3D=E2=80=9Cid=E2=80=9D value=3D=E2=80=9Corg.apache.cordova.co=
nsole=E2=80=9D />
  <param name=3D=E2=80=9Cversion=E2=80=9D value=3D=E2=80=9C0.2.7=E2=80=9D /=
>
</feature>

Whereas plugin.xml <dependency> tags look like:

<dependency id=3D"org.apache.cordova.file" version=3D"1.0.1" />

And the current platform config.xml feature tags look like: (note the
caveat Andrew mentions that these are intended to solve a different problem=
)

<feature name=3D=E2=80=9CConsole=E2=80=9D>
  <param name=3D"ios-package" value=3D"CDVConsole" />
</feature>

Food for thought.

-Michal

On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <purplecabbage@gmail.com>wr=
ote:

> Can we see a mock version of what this all would like in either case?
> I also withdraw my previous +1 for <feature/> after Michal's clarificatio=
n.
>
> Sent from my iPhone
>
> > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mmocny@google.com> wrote:
> >
> > Actually I don't think of platforms as dependencies. Your app doesn't
> need
> > android to run on iOS. It needs plugins. Plugin deps may be specific to
> > certain platforms, but platforms are targets.
> >
> > So I think dependency is not ambiguous with platforms.. Though your app
> may
> > have more deps than just Cordova plugins.
> >> On 23 Apr 2014 10:08, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >>
> >> I like the <param name=3D"registry"> idea!
> >>
> >> The main thing I don't like about <feature>, is that it already means
> >> something different in platform config.xml:
> >>    <feature name=3D"LocalStorage">
> >>        <param name=3D"ios-package" value=3D"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 <
> purplecabbage@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.ercan@gmail.com>
> >> wrote:
> >>>>
> >>>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <agrieve@chromium.or=
g
> >
> >> 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 featu=
re
> >> it
> >>>> is very easily extendible. For instance if someday we want to suppor=
t
> >>>> enterprise plugin registries, we could just add <param name=3D"regis=
try"
> >>>> value=3D"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.kadri@gmail.com>
> >> wrote:
> >>>>>> I prefer <feature>.
> >>>>>>
> >>>>>>
> >>>>>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <
> kamrik@google.com
> >>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I prefer the <dependency> syntax. It's shorter, more intuitive an=
d
> >>>>>>> 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 <mmocny@google.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Gorkem is adding awesome feature to restore plugins/platforms yo=
ur
> >> app
> >>>>>>>> depends on.  There is some debate on the correct syntax to use i=
n
> >> the
> >>>>>>>> config.xml file: do we use (a) plugin.xml style <dependency> tag=
s,
> >> 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 & version=
s
> 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"
> >>
>

--047d7b3a95784ed06e04f7b909d2--