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:09:37 GMT
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