cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Date Thu, 24 Apr 2014 03:34:42 GMT
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 <mmocny@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 <anis.kadri@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"
>> > >> > >>
>> > >> >
>> > >>
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message