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: <plugins> tag, and accessing the plugin list
Date Fri, 15 Nov 2013 17:29:09 GMT
+1

On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana <csantana23@gmail.com> wrote:
> +1
>
> Yep I agree this way users can get list of plugins installed from
> javascript pretty easy on all platforms from a web resource (i.e.
> cordova_plugins.js
> )
>
>
> On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <agrieve@chromium.org>wrote:
>
>> That sounds good to me.
>>
>>
>> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <braden@chromium.org
>> >wrote:
>>
>> > Looking back over all of this discussion, we have a growing trend of
>> > dissatisfaction with the current config file setup. We've talked in the
>> > past about moving to JSON format, Andrew is suggesting above replacing
>> 99%
>> > of <config-file> uses with specialized tags to inject permissions and
>> > <feature>s, my summary in the other thread was pretty disgustingly
>> > complicated, etc.
>> >
>> > 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.
>> >
>> > This modifies a file that is already clearly a build artifact and not
>> > touched by humans. It is fully backward compatible, since the array of JS
>> > modules is unchanged when viewed as an array. And it gets me access the
>> > information I needed in the short term to build the AppHarness
>> > functionality.
>> >
>> > How does that sound?
>> >
>> > Braden
>> >
>> >
>> > On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <agrieve@chromium.org
>> > >wrote:
>> >
>> > > I think the thing that irks me about the proposal to fiddle with
>> > > <feature>s, is that right now plugins put them in <config-file>
tags.
>> > With
>> > > these tags:
>> > >
>> > > - You can specify any target that's an xml file
>> > > - You can specify any xpath in the parent attribute
>> > > - plugman will splice in your XML into the target file if-and-only-if
>> > there
>> > > wasn't already another plugin that spliced in the exact same chunk into
>> > the
>> > > exact same place.
>> > >
>> > > Now, we're proposing to make this <config-file> rule even more complex:
>> > > - You can specify any target that's an xml file
>> > > - You can specify any xpath in the parent attribute
>> > > NEW:
>> > > - If you specify target="config.xml" AND you specify parent xpath that
>> > > evaluates to the same things as parent="/widget" Then:
>> > >    - For each top-level <feature> element in your payload:
>> > >      - Plugman will insert two new <params> into it with your plugin
>> ID &
>> > > version
>> > > - plugman will splice in your XML into the target file if-and-only-if
>> > there
>> > > wasn't already another plugin that spliced in the exact same chunk into
>> > the
>> > > exact same place.
>> > > NEW:
>> > > - If your plugin does not have any <config-file> targets that match
the
>> > > above conditions:
>> > >   - Plugman will add one for you with a default payload of a <feature>
>> > with
>> > > params.
>> > >
>> > >
>> > > I haven't run it past any real-world users, but it if it sounds
>> > complicated
>> > > to me, then I'd be surprised if it wasn't also confusing to others.
>> > >
>> > > Maybe a fallout of this discussion is that it's hurting us to be using
>> > > <config-file> for common things. Seems like it would be simpler for
>> both
>> > > plugman and plugin devs to have <feature> outside of <config-file>.
If
>> > this
>> > > were the case, I'd be much more open to the idea of altering them when
>> we
>> > > spliced them in.
>> > >
>> > > Going a step further, Michal suggested in another thread that we just
>> > > include the plugin.xml files directly in apps. The more I think about
>> > this,
>> > > the more it makes sense to me. Why are we even splicing things into
>> > > config.xml? Seems like we're doing work to lose information. If we just
>> > > included the plugin.xml files directly, we could read out the
>> <feature>,
>> > > <access>, plugin iD & version, even <js-module>s. If we
want to keep
>> all
>> > > the runtime xml in one file, how about splice in the entire plugin.xml
>> > into
>> > > config.xml?
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <anis.kadri@gmail.com>
>> > wrote:
>> > >
>> > > > On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <agrieve@chromium.org
>> >
>> > > > wrote:
>> > > > > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <anis.kadri@gmail.com>
>> > > > wrote:
>> > > > >
>> > > > >> So...
>> > > > >>
>> > > > >> We just had a good chat about this topic with Braden and
Gorkem
>> and
>> > we
>> > > > >> think that adding <param>s to the existing <feature>
tag is better
>> > > > >> than introducing a new one.
>> > > > >>
>> > > > >> Pros:
>> > > > >> - No new tags, less confusion.
>> > > > >
>> > > > > Unless we're going to add a new tag to do what <feature>
currently
>> > > does,
>> > > > > I'd argue having one tag that does two things is more confusing.
>> > > >
>> > > > As you say it's arguable but I tend to base my arguments on
>> real-world
>> > > > users rather than Cordova core developers.
>> > > >
>> > > > >
>> > > > >
>> > > > >>
>> > > > >
>> > > > > - A good path towards having a unique top-level config.xml since
we
>> > > > >> can now identify which plugins are installed from the feature
tag.
>> > > > >> Therefore, we can better handle uninstalls and user edits
to the
>> > file.
>> > > > >>
>> > > > > This makes me think I just don't understand what the proposal
now
>> is.
>> > > An
>> > > > > example would help I think.
>> > > > > Some questions:
>> > > > > - Does this mean we're going to change <feature> to not
directly
>> > define
>> > > > > bridge mappings?
>> > > >
>> > > > No
>> > > >
>> > > > >    - Is the idea to have a new tag within <feature> that
defines
>> the
>> > > > bridge
>> > > > > binding?
>> > > >
>> > > > No
>> > > >
>> > > > > - If not:
>> > > > >    - what are we doing with plugins that define multiple <feature>
>> > > tags?
>> > > >
>> > > > We define two <param>s that hold the plugin ID an version. In
older
>> > > > versions of cordova <feature> was called <plugin> and
the mapping was
>> > > > one-to-one and it still seems to be the case. If for whatever reason
>> > > > one needs to have 2+ <feature>s for one plugin, all <feature>
tags
>> > > > should define <param>s that indicate ID/version.
>> > > >
>> > > > >    - what are we doing if apps directly define <feature>
tags
>> > directly
>> > > in
>> > > > > their config.xml (outside of plugins)? This is still common for
>> > plugins
>> > > > > that haven't been updated to plugman. I think we do this for
>> plugins
>> > > > > bundled with the platforms (e.g. Android's App plugin)
>> > > >
>> > > > I am not sure I understand the question but everything gets defined
>> in
>> > > > the top-level config.xml (plugins, js-only plugins and
>> > > > platform-specific things like Android's App plugin).
>> > > >
>> > > I just wanted to point out that people still copy & paste in <feature>
>> > tags
>> > > directly into their config.xml for plugins that haven't been
>> > plugmanified.
>> > >
>> > >
>> > >
>> > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >>
>> > > > >> Cons:
>> > > > >> - Harder to implement for us. "Should still take less time
than
>> > > > >> arguing on the topic" said Braden ;-)
>> > > > >> - Previous Cordova platforms might or might not choke when
they
>> see
>> > > > >> JS-only plugins listed as <feature>s but it's unlikely.
>> > > > >>
>> > > > > Android chokes:
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
>> > > >
>> > > > Can you be specifc ? From what I read from PluginManager.java and
>> > > > PluginEntry.java is that it gets added to a HashMap but the class
>> only
>> > > > gets instantiated if "onload" <param> is defined or if getPlugin()
is
>> > > > called when JS is called but exec not called for JS-only plugins
>> > > > right?
>> > > >
>> > > Sorry, should have just tried it out before speaking up. I thought
>> > adding a
>> > > null key would be a problem, but it seems as though hash maps do allow
>> > > them.
>> > >
>> > >
>> > > > >
>> > > > >
>> > > > > Not sure if this was considered, but instead of using a config
>> file,
>> > we
>> > > > > could generate a source file that gets compiled in. Would eliminate
>> > any
>> > > > > performance concerns and stay out of files that users might be
>> > peering
>> > > > at.
>> > > >
>> > > > Sure but this would only solve the app-harness problem we could also
>> > > > solve at least two more problems:
>> > > > - Have one canonical config.xml which is a path to making platforms
>> > > > true build artifacts.
>> > > > - Have the ability install all plugins all at once (ala npm install).
>> > > >
>> > > Good points. generating a source file == bad idea.
>> > >
>> > >
>> > >
>> > > >
>> > > >
>> > > > >
>> > > > >
>> > > > >>
>> > > > >>
>> > > > >> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
>> > > > >> <braden@chromium.org> wrote:
>> > > > >> > Following up on my big config-and-metadata summary in
the other
>> > > > thread,
>> > > > >> the
>> > > > >> > file in question here is the platform config.xml (that
is,
>> > > > >> > $PROJECT/platforms/<platform>/.../config.xml,
see my summary).
>> > > > >> > Significantly, this file is written by Plugman and CLI,
and read
>> > by
>> > > > the
>> > > > >> > native platform. The user never reads or writes this
file
>> directly
>> > > in
>> > > > the
>> > > > >> > normal flow of things.
>> > > > >> >
>> > > > >> > Braden
>> > > > >> >
>> > > > >> >
>> > > > >> > On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson
<
>> > > > braden@chromium.org
>> > > > >> >wrote:
>> > > > >> >
>> > > > >> >> There's a bit of a BC issue here because cordova.js
needs to
>> know
>> > > > what
>> > > > >> >> file to inject a <script> tag for, so it can
load the file and
>> > then
>> > > > load
>> > > > >> >> its module. That's why I hesitated to modify the
format of that
>> > > file,
>> > > > >> >> originally. (It currently sets module.exports to
an array of
>> > > > <js-module>
>> > > > >> >> info.) Like Andrew says, entirely possible to make
the change,
>> > just
>> > > > that
>> > > > >> >> some care is required.
>> > > > >> >>
>> > > > >> >> Braden
>> > > > >> >>
>> > > > >> >>
>> > > > >> >> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan Bond-Caron
<
>> > > > >> >> jbondc@gdesolutions.com> wrote:
>> > > > >> >>
>> > > > >> >>> On Thu Nov 14 01:44 PM, Andrew Grieve wrote:
>> > > > >> >>> > I'm going to attempt to summarize in point
form:
>> > > > >> >>> >
>> > > > >> >>> > Goal:
>> > > > >> >>> >  - Make available the list of installed
plugins and their
>> > > > versions to
>> > > > >> >>> native side & JS
>> > > > >> >>> > side.
>> > > > >> >>> >  - Needed by App Harness to know whether
an app is
>> compatible
>> > > with
>> > > > >> its
>> > > > >> >>> > bundled set of plugins.
>> > > > >> >>> >
>> > > > >> >>> > Using cordova_plugins.js:
>> > > > >> >>> >  - It doesn't have the information that
we need
>> > > > >> >>> >  - We could add the extra information,
but not easily since
>> > the
>> > > > file
>> > > > >> >>> exports an
>> > > > >> >>> > array instead of an object.
>> > > > >> >>> >  - This file is not currently parsed by
the native layer, so
>> > > > having
>> > > > >> the
>> > > > >> >>> info here
>> > > > >> >>> > would be an extra IO on start-up.
>> > > > >> >>> >
>> > > > >> >>>
>> > > > >> >>> Great summary :)
>> > > > >> >>>
>> > > > >> >>> Is it difficult to rename ' cordova_plugins.js'
to something
>> > more
>> > > > broad
>> > > > >> >>> 'cordova_meta.js', ' cordova_loader.js', 'cordova_boot.js'
and
>> > > > using an
>> > > > >> >>> object?
>> > > > >> >>> Since it's generated code, first impression
is there's no BC
>> > issue
>> > > > >> other
>> > > > >> >>> than doing another prepare.
>> > > > >> >>>
>> > > > >> >>> Doesn't seem like there's a way to avoid the
extra IO on the
>> > > native
>> > > > >> side
>> > > > >> >>> (e.g. cordova_meta.js). If the detailed list
of installed
>> > plugins
>> > > > is in
>> > > > >> >>> xml, how will the JS side access it?
>> > > > >> >>>
>> > > > >> >>> Broader problem is there's no single cordova
meta file that's
>> > > shared
>> > > > >> >>> between native & js. Considering that on
some platforms,
>> there's
>> > > > only
>> > > > >> >>> JavaScript, putting the information in JSON
seems like a good
>> > > move.
>> > > > >> >>>
>> > > > >> >>>
>> > > > >> >>
>> > > > >>
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>

Mime
View raw message