cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Date Thu, 24 Apr 2014 17:37:23 GMT
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 <mmocny@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 <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