You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Michal Mocny <mm...@google.com> on 2014/04/22 19:31:13 UTC
Looking for input on syntax to use for specifying plugin deps in config.xml
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"
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Mark Koudritsky <ka...@google.com>.
We also need this syntax to support plugins installed for one platform, but
not the other
https://issues.apache.org/jira/browse/CB-6118
On Tue, Apr 22, 2014 at 2:41 PM, Mark Koudritsky <ka...@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 <mm...@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"
>>
>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Brian LeRoux <b...@brian.io>.
I'm in favor of symmetry with the plugins (though an argument for feature
can go the other way).
On Apr 22, 2014 5:52 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> Anis - Gorkem wants <feature> since it works with his IDE. *Why* do
> you prefer <feature>?
>
> On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI <an...@gmail.com> wrote:
> > I prefer <feature>.
> >
> >
> > On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <ka...@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 <mm...@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"
> >> >
> >>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Michal Mocny <mm...@chromium.org>.
Jesse, while the config.xml's share the same name, I think that
input/output argument is invalid. All of: defaults.xml, plugin.xml, and
application level config (sadly named config.xml) are all inputs with
slightly different specs that produce several platform level configs (named
config.xml) also with a slightly different spec.
The fact that the project level config.xml uses <feature/> tag is a valid
argument to consider (I hadn't considered it), I just wanted to correct the
specific reasoning since I think this naming situation bites us repeatedly
into making mistakes.
-Michal
On Wed, Apr 23, 2014 at 12:35 AM, purplecabbage <pu...@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 <go...@gmail.com>
> wrote:
> >
> >> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <ag...@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 <an...@gmail.com>
> wrote:
> >>> I prefer <feature>.
> >>>
> >>>
> >>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <ka...@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 <mm...@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"
> >>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Brian LeRoux <b...@brian.io>.
I'm with Braden on this. Lets pick. We'll hate whatever it is anyhow until
we can get to the great configuration refactoring yak shave bikeshed of 201?
On Thu, Apr 24, 2014 at 10:37 AM, Braden Shepherdson <br...@chromium.org>wrote:
> The widget spec is deprecated. Whatever the outcome of this thread, the
> argument that we should follow the Widget spec is broken. We never followed
> it that closely, with several extensions and usages of a few tags not quite
> as the spec intended.
>
> I'm not particularly invested in any way of spelling the plugin
> dependencies in our XML files.
>
> Braden
>
>
> On Wed, Apr 23, 2014 at 11:34 PM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > Quick code example, which I think demonstrates my dislike of using
> > <feature> in top-level application config.xml:
> >
> > > cordova create Foo && cd Foo
> > > cordova platform add android
> > > cordova plugin add org.apache.cordova.file-transfer
> > > cordova plugin add org.chromium.polyfill.xhr_features@1.0.0
> > > cat ./platforms/android/res/xml/config.xml
> >
> > <?xml version='1.0' encoding='utf-8'?>
> > <widget id="io.cordova.hellocordova" version="0.0.1" xmlns="
> > http://www.w3.org/ns/widgets" xmlns:cdv="
> http://cordova.apache.org/ns/1.0
> > ">
> > <preference name="loglevel" value="DEBUG" />
> > <feature name="App">
> > <param name="android-package" value="org.apache.cordova.App" />
> > </feature>
> > <name>HelloCordova</name>
> > <description>
> > A sample Apache Cordova application that responds to the
> > deviceready event.
> > </description>
> > <author email="dev@cordova.apache.org" href="http://cordova.io">
> > Apache Cordova Team
> > </author>
> > <content src="index.html" />
> > <access origin="*" />
> > <feature name="File">
> > <param name="android-package"
> > value="org.apache.cordova.file.FileUtils" />
> > <param name="onload" value="true" />
> > </feature>
> > <feature name="FileTransfer">
> > <param name="android-package"
> > value="org.apache.cordova.filetransfer.FileTransfer" />
> > </feature>
> > </widget>
> >
> >
> > Things to notice:
> > (1) The first plugin added has a dependency which ends up in platform
> > config <feature> list, but its *not* actually an explicit dep for my
> > application.
> > (2) The second plugin added is not referenced in the <feature> list at
> all
> > (since it is a js-module only plugin), buts it *is* actually an explicit
> > dep for my application.
> > (3) These <feature> tags are not easy to adjust, since they are specified
> > in plugin.xml, as such:
> >
> > > cat plugins/org.apache.cordova.file-transfer/plugin.xml
> > ...
> > <platform name="android">
> > <config-file target="res/xml/config.xml" parent="/*">
> > <feature name="FileTransfer" >
> > <param name="android-package"
> > value="org.apache.cordova.filetransfer.FileTransfer"/>
> > </feature>
> > </config-file>
> > ...
> >
> >
> > Now, if we want this application to depend explicitly on
> > (org.apache.cordova.file-transfer,
> org.chromium.polyfill.xhr_features@1.0.0
> > ),
> > and we chose to use <feature> as the tag to do so, the top-level app
> config
> > would look something like this:
> >
> > > cat ./config.xml
> > <?xml version='1.0' encoding='utf-8'?>
> > <widget id="io.cordova.hellocordova" version="0.0.1" xmlns="
> > http://www.w3.org/ns/widgets" xmlns:cdv="
> http://cordova.apache.org/ns/1.0
> > ">
> > <name>HelloCordova</name>
> > <description>
> > A sample Apache Cordova application that responds to the
> > deviceready event.
> > </description>
> > <author email="dev@cordova.apache.org" href="http://cordova.io">
> > Apache Cordova Team
> > </author>
> > <content src="index.html" />
> > <access origin="*" />
> > <feature>
> > <param name=“id” value=“org.apache.cordova.file-transfer” />
> > </feature>
> > <feature>
> > <param name=“id” value=“org.chromium.polyfill.xhr_features” />
> > <param name=“version” value=“1.0.0” />
> > </feature>
> > </widget>
> >
> >
> > I think, if you look closely, that that means there would be literally 0
> > overlap between the current semantics and the proposal. The params
> > specified differs, the names/ids used differs, the actual set of plugins
> > listed differs, and, most importantly, the goals differ.
> >
> > Thats surely not going to be easy for users when they go google for
> answers
> > regarding syntax/semantics.
> >
> >
> >
> >
> > On Wed, Apr 23, 2014 at 11:09 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> >
> > > So I re-read that thread, and I think it's easiest to just copy the
> final
> > > summary:
> > >
> > > "I propose three things:
> > > 1. Punt all discussion of overhauling configuration files to the new
> > year.
> > > 2. Drop my proposals above, as well as the summary Anis posted of last
> > > night's discussion.
> > > 3. Solve the immediate use-case of AppHarness wanting to know what
> > plugins
> > > are installed by injecting that object into a new key attached to the
> > array
> > > of JS modules in cordova_plugins.js."
> > >
> > > Also: "We have clearly accumulated some technical debt here as it is
> > > difficult to reason (even describe) the config file dog pile."
> > >
> > > Just stating that we shouldn't use those old proposals as an argument
> > > here. (though there are some great nuggets in that thread we can learn
> > > from)
> > >
> > > -Michal
> > >
> > >
> > > On Wed, Apr 23, 2014 at 10:17 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >
> > >> We've already had a discussion about this very topic in the past [1].
> > The
> > >> reason why I prefer <feature> is because it's already used in
> platforms.
> > >> Therefore it would be the right path towards having a unique top-level
> > >> config.xml and platforms as true build artifacts.
> > >> On iOS and Android plugins are loaded on demand and <feature> tags
> that
> > >> don't have a matching native implementation (ie JS-only plugins)
> should
> > >> just get ignored.
> > >> I actually don't care as much about IDE support or W3C spec
> conformity.
> > >>
> > >> [1]
> > >>
> > >>
> >
> http://callback.markmail.org/message/fydyv7gh47odpemk?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+app+harness+%3Cfeature%3E
> > >>
> > >>
> > >> On Wed, Apr 23, 2014 at 10:58 AM, Andrew Grieve <agrieve@chromium.org
> > >> >wrote:
> > >>
> > >> > On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <
> gorkem.ercan@gmail.com
> > >
> > >> > wrote:
> > >> > > On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <
> mmocny@chromium.org>
> > >> > wrote:
> > >> > >
> > >> > >> 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=bc60WAQdOjE
> > >> > >>
> > >> > >> The syntax for deps in that patch currently uses <feature> tags
> and
> > >> > looks
> > >> > >> like this:
> > >> > >>
> > >> > >> <feature name=“Console”>
> > >> > >> <param name=“id” value=“org.apache.cordova.console” />
> > >> > >> <param name=“version” value=“0.2.7” />
> > >> > >> </feature>
> > >> > >>
> > >> > >> Whereas plugin.xml <dependency> tags look like:
> > >> > >>
> > >> > >> <dependency id="org.apache.cordova.file" version="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=“Console”>
> > >> > >> <param name="ios-package" value="CDVConsole" />
> > >> > >> </feature>
> > >> > >>
> > >> > >>
> > >> > > One could merge the params as below, if one day we actually have a
> > >> single
> > >> > > config.xml file. Although id and version are planned to be used at
> > the
> > >> > > build time at the moment I think something like app harness could
> > >> > > appreciate their existence at the runtime.
> > >> > >
> > >> > > <feature name=“Console”>
> > >> > > <param name="ios-package" value="CDVConsole" />
> > >> > > <param name=“id” value=“org.apache.cordova.console” />
> > >> > > <param name=“version” value=“0.2.7” />
> > >> > > </feature>
> > >> >
> > >> > Definitely useful to have at runtime. Currently app-harness tacks
> them
> > >> > onto cordova_plugins.js in an ugly way!
> > >> >
> > >> > I don't think they could be merged, because the app developer
> doesn't
> > >> > actually know the name="value" part, only the plugin does.
> > >> >
> > >> > E.g. what you'd actually see in top-level config.xml is:
> > >> >
> > >> > <feature>
> > >> > <param name=“id” value=“org.apache.cordova.console” />
> > >> > <param name=“version” value=“0.2.7” />
> > >> > </feature>
> > >> >
> > >> > or maybe:
> > >> > <feature name="org.apache.cordova.console">
> > >> > <param name=“version” value=“0.2.7” />
> > >> > </feature>
> > >> >
> > >> > or maybe:
> > >> > <feature name="org.apache.cordova.console@0.2.7" />
> > >> >
> > >> >
> > >> > But the point is, the name="" attribute that you see in the platform
> > >> > config.xml is a token that us used in the bridge, and is known only
> by
> > >> > the plugin.
> > >> >
> > >> > >
> > >> > >
> > >> > >
> > >> > >> Food for thought.
> > >> > >>
> > >> > >> -Michal
> > >> > >>
> > >> > >> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <
> > >> > purplecabbage@gmail.com
> > >> > >> >wrote:
> > >> > >>
> > >> > >> > 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
> > >> > >> clarification.
> > >> > >> >
> > >> > >> > 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="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 <
> > >> > >> > 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.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.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
> > >> > >> 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 <
> > >> > mmocny@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"
> > >> > >> > >>
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> > >
> > >
> >
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Braden Shepherdson <br...@chromium.org>.
The widget spec is deprecated. Whatever the outcome of this thread, the
argument that we should follow the Widget spec is broken. We never followed
it that closely, with several extensions and usages of a few tags not quite
as the spec intended.
I'm not particularly invested in any way of spelling the plugin
dependencies in our XML files.
Braden
On Wed, Apr 23, 2014 at 11:34 PM, Michal Mocny <mm...@chromium.org> wrote:
> Quick code example, which I think demonstrates my dislike of using
> <feature> in top-level application config.xml:
>
> > cordova create Foo && cd Foo
> > cordova platform add android
> > cordova plugin add org.apache.cordova.file-transfer
> > cordova plugin add org.chromium.polyfill.xhr_features@1.0.0
> > cat ./platforms/android/res/xml/config.xml
>
> <?xml version='1.0' encoding='utf-8'?>
> <widget id="io.cordova.hellocordova" version="0.0.1" xmlns="
> http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0
> ">
> <preference name="loglevel" value="DEBUG" />
> <feature name="App">
> <param name="android-package" value="org.apache.cordova.App" />
> </feature>
> <name>HelloCordova</name>
> <description>
> A sample Apache Cordova application that responds to the
> deviceready event.
> </description>
> <author email="dev@cordova.apache.org" href="http://cordova.io">
> Apache Cordova Team
> </author>
> <content src="index.html" />
> <access origin="*" />
> <feature name="File">
> <param name="android-package"
> value="org.apache.cordova.file.FileUtils" />
> <param name="onload" value="true" />
> </feature>
> <feature name="FileTransfer">
> <param name="android-package"
> value="org.apache.cordova.filetransfer.FileTransfer" />
> </feature>
> </widget>
>
>
> Things to notice:
> (1) The first plugin added has a dependency which ends up in platform
> config <feature> list, but its *not* actually an explicit dep for my
> application.
> (2) The second plugin added is not referenced in the <feature> list at all
> (since it is a js-module only plugin), buts it *is* actually an explicit
> dep for my application.
> (3) These <feature> tags are not easy to adjust, since they are specified
> in plugin.xml, as such:
>
> > cat plugins/org.apache.cordova.file-transfer/plugin.xml
> ...
> <platform name="android">
> <config-file target="res/xml/config.xml" parent="/*">
> <feature name="FileTransfer" >
> <param name="android-package"
> value="org.apache.cordova.filetransfer.FileTransfer"/>
> </feature>
> </config-file>
> ...
>
>
> Now, if we want this application to depend explicitly on
> (org.apache.cordova.file-transfer, org.chromium.polyfill.xhr_features@1.0.0
> ),
> and we chose to use <feature> as the tag to do so, the top-level app config
> would look something like this:
>
> > cat ./config.xml
> <?xml version='1.0' encoding='utf-8'?>
> <widget id="io.cordova.hellocordova" version="0.0.1" xmlns="
> http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0
> ">
> <name>HelloCordova</name>
> <description>
> A sample Apache Cordova application that responds to the
> deviceready event.
> </description>
> <author email="dev@cordova.apache.org" href="http://cordova.io">
> Apache Cordova Team
> </author>
> <content src="index.html" />
> <access origin="*" />
> <feature>
> <param name=“id” value=“org.apache.cordova.file-transfer” />
> </feature>
> <feature>
> <param name=“id” value=“org.chromium.polyfill.xhr_features” />
> <param name=“version” value=“1.0.0” />
> </feature>
> </widget>
>
>
> I think, if you look closely, that that means there would be literally 0
> overlap between the current semantics and the proposal. The params
> specified differs, the names/ids used differs, the actual set of plugins
> listed differs, and, most importantly, the goals differ.
>
> Thats surely not going to be easy for users when they go google for answers
> regarding syntax/semantics.
>
>
>
>
> On Wed, Apr 23, 2014 at 11:09 PM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > So I re-read that thread, and I think it's easiest to just copy the final
> > summary:
> >
> > "I propose three things:
> > 1. Punt all discussion of overhauling configuration files to the new
> year.
> > 2. Drop my proposals above, as well as the summary Anis posted of last
> > night's discussion.
> > 3. Solve the immediate use-case of AppHarness wanting to know what
> plugins
> > are installed by injecting that object into a new key attached to the
> array
> > of JS modules in cordova_plugins.js."
> >
> > Also: "We have clearly accumulated some technical debt here as it is
> > difficult to reason (even describe) the config file dog pile."
> >
> > Just stating that we shouldn't use those old proposals as an argument
> > here. (though there are some great nuggets in that thread we can learn
> > from)
> >
> > -Michal
> >
> >
> > On Wed, Apr 23, 2014 at 10:17 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> >> We've already had a discussion about this very topic in the past [1].
> The
> >> reason why I prefer <feature> is because it's already used in platforms.
> >> Therefore it would be the right path towards having a unique top-level
> >> config.xml and platforms as true build artifacts.
> >> On iOS and Android plugins are loaded on demand and <feature> tags that
> >> don't have a matching native implementation (ie JS-only plugins) should
> >> just get ignored.
> >> I actually don't care as much about IDE support or W3C spec conformity.
> >>
> >> [1]
> >>
> >>
> http://callback.markmail.org/message/fydyv7gh47odpemk?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+app+harness+%3Cfeature%3E
> >>
> >>
> >> On Wed, Apr 23, 2014 at 10:58 AM, Andrew Grieve <agrieve@chromium.org
> >> >wrote:
> >>
> >> > On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <gorkem.ercan@gmail.com
> >
> >> > wrote:
> >> > > On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mm...@chromium.org>
> >> > wrote:
> >> > >
> >> > >> 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=bc60WAQdOjE
> >> > >>
> >> > >> The syntax for deps in that patch currently uses <feature> tags and
> >> > looks
> >> > >> like this:
> >> > >>
> >> > >> <feature name=“Console”>
> >> > >> <param name=“id” value=“org.apache.cordova.console” />
> >> > >> <param name=“version” value=“0.2.7” />
> >> > >> </feature>
> >> > >>
> >> > >> Whereas plugin.xml <dependency> tags look like:
> >> > >>
> >> > >> <dependency id="org.apache.cordova.file" version="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=“Console”>
> >> > >> <param name="ios-package" value="CDVConsole" />
> >> > >> </feature>
> >> > >>
> >> > >>
> >> > > One could merge the params as below, if one day we actually have a
> >> single
> >> > > config.xml file. Although id and version are planned to be used at
> the
> >> > > build time at the moment I think something like app harness could
> >> > > appreciate their existence at the runtime.
> >> > >
> >> > > <feature name=“Console”>
> >> > > <param name="ios-package" value="CDVConsole" />
> >> > > <param name=“id” value=“org.apache.cordova.console” />
> >> > > <param name=“version” value=“0.2.7” />
> >> > > </feature>
> >> >
> >> > Definitely useful to have at runtime. Currently app-harness tacks them
> >> > onto cordova_plugins.js in an ugly way!
> >> >
> >> > I don't think they could be merged, because the app developer doesn't
> >> > actually know the name="value" part, only the plugin does.
> >> >
> >> > E.g. what you'd actually see in top-level config.xml is:
> >> >
> >> > <feature>
> >> > <param name=“id” value=“org.apache.cordova.console” />
> >> > <param name=“version” value=“0.2.7” />
> >> > </feature>
> >> >
> >> > or maybe:
> >> > <feature name="org.apache.cordova.console">
> >> > <param name=“version” value=“0.2.7” />
> >> > </feature>
> >> >
> >> > or maybe:
> >> > <feature name="org.apache.cordova.console@0.2.7" />
> >> >
> >> >
> >> > But the point is, the name="" attribute that you see in the platform
> >> > config.xml is a token that us used in the bridge, and is known only by
> >> > the plugin.
> >> >
> >> > >
> >> > >
> >> > >
> >> > >> Food for thought.
> >> > >>
> >> > >> -Michal
> >> > >>
> >> > >> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <
> >> > purplecabbage@gmail.com
> >> > >> >wrote:
> >> > >>
> >> > >> > 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
> >> > >> clarification.
> >> > >> >
> >> > >> > Sent from my iPhone
> >> > >> >
> >> > >> > > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org>
> >> > wrote:
> >> > >> > >>
> >> > >> > >> 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 <
> >> > >> > 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.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.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
> >> > >> 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 <
> >> > mmocny@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"
> >> > >> > >>
> >> > >> >
> >> > >>
> >> >
> >>
> >
> >
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Michal Mocny <mm...@chromium.org>.
Quick code example, which I think demonstrates my dislike of using
<feature> in top-level application config.xml:
> cordova create Foo && cd Foo
> cordova platform add android
> cordova plugin add org.apache.cordova.file-transfer
> cordova plugin add org.chromium.polyfill.xhr_features@1.0.0
> cat ./platforms/android/res/xml/config.xml
<?xml version='1.0' encoding='utf-8'?>
<widget id="io.cordova.hellocordova" version="0.0.1" xmlns="
http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0">
<preference name="loglevel" value="DEBUG" />
<feature name="App">
<param name="android-package" value="org.apache.cordova.App" />
</feature>
<name>HelloCordova</name>
<description>
A sample Apache Cordova application that responds to the
deviceready event.
</description>
<author email="dev@cordova.apache.org" href="http://cordova.io">
Apache Cordova Team
</author>
<content src="index.html" />
<access origin="*" />
<feature name="File">
<param name="android-package"
value="org.apache.cordova.file.FileUtils" />
<param name="onload" value="true" />
</feature>
<feature name="FileTransfer">
<param name="android-package"
value="org.apache.cordova.filetransfer.FileTransfer" />
</feature>
</widget>
Things to notice:
(1) The first plugin added has a dependency which ends up in platform
config <feature> list, but its *not* actually an explicit dep for my
application.
(2) The second plugin added is not referenced in the <feature> list at all
(since it is a js-module only plugin), buts it *is* actually an explicit
dep for my application.
(3) These <feature> tags are not easy to adjust, since they are specified
in plugin.xml, as such:
> cat plugins/org.apache.cordova.file-transfer/plugin.xml
...
<platform name="android">
<config-file target="res/xml/config.xml" parent="/*">
<feature name="FileTransfer" >
<param name="android-package"
value="org.apache.cordova.filetransfer.FileTransfer"/>
</feature>
</config-file>
...
Now, if we want this application to depend explicitly on
(org.apache.cordova.file-transfer, org.chromium.polyfill.xhr_features@1.0.0),
and we chose to use <feature> as the tag to do so, the top-level app config
would look something like this:
> cat ./config.xml
<?xml version='1.0' encoding='utf-8'?>
<widget id="io.cordova.hellocordova" version="0.0.1" xmlns="
http://www.w3.org/ns/widgets" xmlns:cdv="http://cordova.apache.org/ns/1.0">
<name>HelloCordova</name>
<description>
A sample Apache Cordova application that responds to the
deviceready event.
</description>
<author email="dev@cordova.apache.org" href="http://cordova.io">
Apache Cordova Team
</author>
<content src="index.html" />
<access origin="*" />
<feature>
<param name=“id” value=“org.apache.cordova.file-transfer” />
</feature>
<feature>
<param name=“id” value=“org.chromium.polyfill.xhr_features” />
<param name=“version” value=“1.0.0” />
</feature>
</widget>
I think, if you look closely, that that means there would be literally 0
overlap between the current semantics and the proposal. The params
specified differs, the names/ids used differs, the actual set of plugins
listed differs, and, most importantly, the goals differ.
Thats surely not going to be easy for users when they go google for answers
regarding syntax/semantics.
On Wed, Apr 23, 2014 at 11:09 PM, Michal Mocny <mm...@chromium.org> wrote:
> So I re-read that thread, and I think it's easiest to just copy the final
> summary:
>
> "I propose three things:
> 1. Punt all discussion of overhauling configuration files to the new year.
> 2. Drop my proposals above, as well as the summary Anis posted of last
> night's discussion.
> 3. Solve the immediate use-case of AppHarness wanting to know what plugins
> are installed by injecting that object into a new key attached to the array
> of JS modules in cordova_plugins.js."
>
> Also: "We have clearly accumulated some technical debt here as it is
> difficult to reason (even describe) the config file dog pile."
>
> Just stating that we shouldn't use those old proposals as an argument
> here. (though there are some great nuggets in that thread we can learn
> from)
>
> -Michal
>
>
> On Wed, Apr 23, 2014 at 10:17 PM, Anis KADRI <an...@gmail.com> wrote:
>
>> We've already had a discussion about this very topic in the past [1]. The
>> reason why I prefer <feature> is because it's already used in platforms.
>> Therefore it would be the right path towards having a unique top-level
>> config.xml and platforms as true build artifacts.
>> On iOS and Android plugins are loaded on demand and <feature> tags that
>> don't have a matching native implementation (ie JS-only plugins) should
>> just get ignored.
>> I actually don't care as much about IDE support or W3C spec conformity.
>>
>> [1]
>>
>> http://callback.markmail.org/message/fydyv7gh47odpemk?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+app+harness+%3Cfeature%3E
>>
>>
>> On Wed, Apr 23, 2014 at 10:58 AM, Andrew Grieve <agrieve@chromium.org
>> >wrote:
>>
>> > On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <go...@gmail.com>
>> > wrote:
>> > > On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mm...@chromium.org>
>> > wrote:
>> > >
>> > >> 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=bc60WAQdOjE
>> > >>
>> > >> The syntax for deps in that patch currently uses <feature> tags and
>> > looks
>> > >> like this:
>> > >>
>> > >> <feature name=“Console”>
>> > >> <param name=“id” value=“org.apache.cordova.console” />
>> > >> <param name=“version” value=“0.2.7” />
>> > >> </feature>
>> > >>
>> > >> Whereas plugin.xml <dependency> tags look like:
>> > >>
>> > >> <dependency id="org.apache.cordova.file" version="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=“Console”>
>> > >> <param name="ios-package" value="CDVConsole" />
>> > >> </feature>
>> > >>
>> > >>
>> > > One could merge the params as below, if one day we actually have a
>> single
>> > > config.xml file. Although id and version are planned to be used at the
>> > > build time at the moment I think something like app harness could
>> > > appreciate their existence at the runtime.
>> > >
>> > > <feature name=“Console”>
>> > > <param name="ios-package" value="CDVConsole" />
>> > > <param name=“id” value=“org.apache.cordova.console” />
>> > > <param name=“version” value=“0.2.7” />
>> > > </feature>
>> >
>> > Definitely useful to have at runtime. Currently app-harness tacks them
>> > onto cordova_plugins.js in an ugly way!
>> >
>> > I don't think they could be merged, because the app developer doesn't
>> > actually know the name="value" part, only the plugin does.
>> >
>> > E.g. what you'd actually see in top-level config.xml is:
>> >
>> > <feature>
>> > <param name=“id” value=“org.apache.cordova.console” />
>> > <param name=“version” value=“0.2.7” />
>> > </feature>
>> >
>> > or maybe:
>> > <feature name="org.apache.cordova.console">
>> > <param name=“version” value=“0.2.7” />
>> > </feature>
>> >
>> > or maybe:
>> > <feature name="org.apache.cordova.console@0.2.7" />
>> >
>> >
>> > But the point is, the name="" attribute that you see in the platform
>> > config.xml is a token that us used in the bridge, and is known only by
>> > the plugin.
>> >
>> > >
>> > >
>> > >
>> > >> Food for thought.
>> > >>
>> > >> -Michal
>> > >>
>> > >> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <
>> > purplecabbage@gmail.com
>> > >> >wrote:
>> > >>
>> > >> > 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
>> > >> clarification.
>> > >> >
>> > >> > Sent from my iPhone
>> > >> >
>> > >> > > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org>
>> > wrote:
>> > >> > >>
>> > >> > >> 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 <
>> > >> > 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.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.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
>> > >> 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 <
>> > mmocny@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"
>> > >> > >>
>> > >> >
>> > >>
>> >
>>
>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Michal Mocny <mm...@chromium.org>.
So I re-read that thread, and I think it's easiest to just copy the final
summary:
"I propose three things:
1. Punt all discussion of overhauling configuration files to the new year.
2. Drop my proposals above, as well as the summary Anis posted of last
night's discussion.
3. Solve the immediate use-case of AppHarness wanting to know what plugins
are installed by injecting that object into a new key attached to the array
of JS modules in cordova_plugins.js."
Also: "We have clearly accumulated some technical debt here as it is
difficult to reason (even describe) the config file dog pile."
Just stating that we shouldn't use those old proposals as an argument here.
(though there are some great nuggets in that thread we can learn from)
-Michal
On Wed, Apr 23, 2014 at 10:17 PM, Anis KADRI <an...@gmail.com> wrote:
> We've already had a discussion about this very topic in the past [1]. The
> reason why I prefer <feature> is because it's already used in platforms.
> Therefore it would be the right path towards having a unique top-level
> config.xml and platforms as true build artifacts.
> On iOS and Android plugins are loaded on demand and <feature> tags that
> don't have a matching native implementation (ie JS-only plugins) should
> just get ignored.
> I actually don't care as much about IDE support or W3C spec conformity.
>
> [1]
>
> http://callback.markmail.org/message/fydyv7gh47odpemk?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+app+harness+%3Cfeature%3E
>
>
> On Wed, Apr 23, 2014 at 10:58 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <go...@gmail.com>
> > wrote:
> > > On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > >> 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=bc60WAQdOjE
> > >>
> > >> The syntax for deps in that patch currently uses <feature> tags and
> > looks
> > >> like this:
> > >>
> > >> <feature name=“Console”>
> > >> <param name=“id” value=“org.apache.cordova.console” />
> > >> <param name=“version” value=“0.2.7” />
> > >> </feature>
> > >>
> > >> Whereas plugin.xml <dependency> tags look like:
> > >>
> > >> <dependency id="org.apache.cordova.file" version="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=“Console”>
> > >> <param name="ios-package" value="CDVConsole" />
> > >> </feature>
> > >>
> > >>
> > > One could merge the params as below, if one day we actually have a
> single
> > > config.xml file. Although id and version are planned to be used at the
> > > build time at the moment I think something like app harness could
> > > appreciate their existence at the runtime.
> > >
> > > <feature name=“Console”>
> > > <param name="ios-package" value="CDVConsole" />
> > > <param name=“id” value=“org.apache.cordova.console” />
> > > <param name=“version” value=“0.2.7” />
> > > </feature>
> >
> > Definitely useful to have at runtime. Currently app-harness tacks them
> > onto cordova_plugins.js in an ugly way!
> >
> > I don't think they could be merged, because the app developer doesn't
> > actually know the name="value" part, only the plugin does.
> >
> > E.g. what you'd actually see in top-level config.xml is:
> >
> > <feature>
> > <param name=“id” value=“org.apache.cordova.console” />
> > <param name=“version” value=“0.2.7” />
> > </feature>
> >
> > or maybe:
> > <feature name="org.apache.cordova.console">
> > <param name=“version” value=“0.2.7” />
> > </feature>
> >
> > or maybe:
> > <feature name="org.apache.cordova.console@0.2.7" />
> >
> >
> > But the point is, the name="" attribute that you see in the platform
> > config.xml is a token that us used in the bridge, and is known only by
> > the plugin.
> >
> > >
> > >
> > >
> > >> Food for thought.
> > >>
> > >> -Michal
> > >>
> > >> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <
> > purplecabbage@gmail.com
> > >> >wrote:
> > >>
> > >> > 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
> > >> clarification.
> > >> >
> > >> > Sent from my iPhone
> > >> >
> > >> > > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org>
> > wrote:
> > >> > >>
> > >> > >> 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 <
> > >> > 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.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.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
> > >> 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 <
> > mmocny@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"
> > >> > >>
> > >> >
> > >>
> >
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Anis KADRI <an...@gmail.com>.
We've already had a discussion about this very topic in the past [1]. The
reason why I prefer <feature> is because it's already used in platforms.
Therefore it would be the right path towards having a unique top-level
config.xml and platforms as true build artifacts.
On iOS and Android plugins are loaded on demand and <feature> tags that
don't have a matching native implementation (ie JS-only plugins) should
just get ignored.
I actually don't care as much about IDE support or W3C spec conformity.
[1]
http://callback.markmail.org/message/fydyv7gh47odpemk?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+app+harness+%3Cfeature%3E
On Wed, Apr 23, 2014 at 10:58 AM, Andrew Grieve <ag...@chromium.org>wrote:
> On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <go...@gmail.com>
> wrote:
> > On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> >> 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=bc60WAQdOjE
> >>
> >> The syntax for deps in that patch currently uses <feature> tags and
> looks
> >> like this:
> >>
> >> <feature name=“Console”>
> >> <param name=“id” value=“org.apache.cordova.console” />
> >> <param name=“version” value=“0.2.7” />
> >> </feature>
> >>
> >> Whereas plugin.xml <dependency> tags look like:
> >>
> >> <dependency id="org.apache.cordova.file" version="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=“Console”>
> >> <param name="ios-package" value="CDVConsole" />
> >> </feature>
> >>
> >>
> > One could merge the params as below, if one day we actually have a single
> > config.xml file. Although id and version are planned to be used at the
> > build time at the moment I think something like app harness could
> > appreciate their existence at the runtime.
> >
> > <feature name=“Console”>
> > <param name="ios-package" value="CDVConsole" />
> > <param name=“id” value=“org.apache.cordova.console” />
> > <param name=“version” value=“0.2.7” />
> > </feature>
>
> Definitely useful to have at runtime. Currently app-harness tacks them
> onto cordova_plugins.js in an ugly way!
>
> I don't think they could be merged, because the app developer doesn't
> actually know the name="value" part, only the plugin does.
>
> E.g. what you'd actually see in top-level config.xml is:
>
> <feature>
> <param name=“id” value=“org.apache.cordova.console” />
> <param name=“version” value=“0.2.7” />
> </feature>
>
> or maybe:
> <feature name="org.apache.cordova.console">
> <param name=“version” value=“0.2.7” />
> </feature>
>
> or maybe:
> <feature name="org.apache.cordova.console@0.2.7" />
>
>
> But the point is, the name="" attribute that you see in the platform
> config.xml is a token that us used in the bridge, and is known only by
> the plugin.
>
> >
> >
> >
> >> Food for thought.
> >>
> >> -Michal
> >>
> >> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <
> purplecabbage@gmail.com
> >> >wrote:
> >>
> >> > 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
> >> clarification.
> >> >
> >> > Sent from my iPhone
> >> >
> >> > > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org>
> wrote:
> >> > >>
> >> > >> 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 <
> >> > 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.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.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
> >> 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 <
> mmocny@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"
> >> > >>
> >> >
> >>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Andrew Grieve <ag...@chromium.org>.
On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <go...@gmail.com> wrote:
> On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> 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=bc60WAQdOjE
>>
>> The syntax for deps in that patch currently uses <feature> tags and looks
>> like this:
>>
>> <feature name=“Console”>
>> <param name=“id” value=“org.apache.cordova.console” />
>> <param name=“version” value=“0.2.7” />
>> </feature>
>>
>> Whereas plugin.xml <dependency> tags look like:
>>
>> <dependency id="org.apache.cordova.file" version="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=“Console”>
>> <param name="ios-package" value="CDVConsole" />
>> </feature>
>>
>>
> One could merge the params as below, if one day we actually have a single
> config.xml file. Although id and version are planned to be used at the
> build time at the moment I think something like app harness could
> appreciate their existence at the runtime.
>
> <feature name=“Console”>
> <param name="ios-package" value="CDVConsole" />
> <param name=“id” value=“org.apache.cordova.console” />
> <param name=“version” value=“0.2.7” />
> </feature>
Definitely useful to have at runtime. Currently app-harness tacks them
onto cordova_plugins.js in an ugly way!
I don't think they could be merged, because the app developer doesn't
actually know the name="value" part, only the plugin does.
E.g. what you'd actually see in top-level config.xml is:
<feature>
<param name=“id” value=“org.apache.cordova.console” />
<param name=“version” value=“0.2.7” />
</feature>
or maybe:
<feature name="org.apache.cordova.console">
<param name=“version” value=“0.2.7” />
</feature>
or maybe:
<feature name="org.apache.cordova.console@0.2.7" />
But the point is, the name="" attribute that you see in the platform
config.xml is a token that us used in the bridge, and is known only by
the plugin.
>
>
>
>> Food for thought.
>>
>> -Michal
>>
>> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <purplecabbage@gmail.com
>> >wrote:
>>
>> > 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
>> clarification.
>> >
>> > Sent from my iPhone
>> >
>> > > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org> wrote:
>> > >>
>> > >> 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 <
>> > 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 <go...@gmail.com>
>> > >> wrote:
>> > >>>>
>> > >>>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <
>> agrieve@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.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
>> 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 <mmocny@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"
>> > >>
>> >
>>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Gorkem Ercan <go...@gmail.com>.
On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mm...@chromium.org> wrote:
> 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=bc60WAQdOjE
>
> The syntax for deps in that patch currently uses <feature> tags and looks
> like this:
>
> <feature name=“Console”>
> <param name=“id” value=“org.apache.cordova.console” />
> <param name=“version” value=“0.2.7” />
> </feature>
>
> Whereas plugin.xml <dependency> tags look like:
>
> <dependency id="org.apache.cordova.file" version="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=“Console”>
> <param name="ios-package" value="CDVConsole" />
> </feature>
>
>
One could merge the params as below, if one day we actually have a single
config.xml file. Although id and version are planned to be used at the
build time at the moment I think something like app harness could
appreciate their existence at the runtime.
<feature name=“Console”>
<param name="ios-package" value="CDVConsole" />
<param name=“id” value=“org.apache.cordova.console” />
<param name=“version” value=“0.2.7” />
</feature>
> Food for thought.
>
> -Michal
>
> On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <purplecabbage@gmail.com
> >wrote:
>
> > 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
> clarification.
> >
> > Sent from my iPhone
> >
> > > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org> wrote:
> > >>
> > >> 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 <
> > 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 <go...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <
> agrieve@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.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
> 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 <mmocny@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"
> > >>
> >
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Michal Mocny <mm...@chromium.org>.
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=bc60WAQdOjE
The syntax for deps in that patch currently uses <feature> tags and looks
like this:
<feature name=“Console”>
<param name=“id” value=“org.apache.cordova.console” />
<param name=“version” value=“0.2.7” />
</feature>
Whereas plugin.xml <dependency> tags look like:
<dependency id="org.apache.cordova.file" version="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=“Console”>
<param name="ios-package" value="CDVConsole" />
</feature>
Food for thought.
-Michal
On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <pu...@gmail.com>wrote:
> 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 clarification.
>
> Sent from my iPhone
>
> > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org> wrote:
> >>
> >> 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 <
> 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 <go...@gmail.com>
> >> wrote:
> >>>>
> >>>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <agrieve@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 <an...@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 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 <mm...@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"
> >>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by purplecabbage <pu...@gmail.com>.
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 clarification.
Sent from my iPhone
> On Apr 23, 2014, at 9:03 AM, Michal Mocny <mm...@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" <ag...@chromium.org> wrote:
>>
>> 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 <pu...@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 <go...@gmail.com>
>> wrote:
>>>>
>>>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <ag...@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 <an...@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 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 <mm...@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"
>>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Michal Mocny <mm...@google.com>.
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" <ag...@chromium.org> wrote:
> 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 <pu...@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 <go...@gmail.com>
> wrote:
> >>
> >>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <ag...@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 <an...@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 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 <mm...@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"
> >>>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Andrew Grieve <ag...@chromium.org>.
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 <pu...@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 <go...@gmail.com> wrote:
>>
>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <ag...@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 <an...@gmail.com> wrote:
>>>> I prefer <feature>.
>>>>
>>>>
>>>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <ka...@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 <mm...@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"
>>>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by purplecabbage <pu...@gmail.com>.
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 <go...@gmail.com> wrote:
>
>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <ag...@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 <an...@gmail.com> wrote:
>>> I prefer <feature>.
>>>
>>>
>>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <ka...@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 <mm...@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"
>>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Gorkem Ercan <go...@gmail.com>.
On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <ag...@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 <an...@gmail.com> wrote:
> > I prefer <feature>.
> >
> >
> > On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <ka...@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 <mm...@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"
> >> >
> >>
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Andrew Grieve <ag...@chromium.org>.
Anis - Gorkem wants <feature> since it works with his IDE. *Why* do
you prefer <feature>?
On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI <an...@gmail.com> wrote:
> I prefer <feature>.
>
>
> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <ka...@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 <mm...@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"
>> >
>>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Anis KADRI <an...@gmail.com>.
I prefer <feature>.
On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <ka...@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 <mm...@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"
> >
>
Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Posted by Mark Koudritsky <ka...@google.com>.
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 <mm...@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"
>