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 Thu, 14 Nov 2013 22:14:34 GMT
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.
- 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.

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.



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