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 04:19:36 GMT
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).

>
>
>
>
>>
>> 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?
>
>
> 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).


>
>
>>
>>
>> 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.
>> >>>
>> >>>
>> >>
>>

Mime
View raw message