cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Date Thu, 24 Apr 2014 02:17:29 GMT
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