cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: A word about plugins
Date Fri, 15 Mar 2013 11:42:02 GMT
Yea, this isn't pretty. Agree w/ Anis to cross the bridge when we get there.

Also agree w/ Fil's idea that dependencies are ok but a plugin only
gets loaded once and if a dep requires a different version then we
should fail noisily.

In a perfect world, that will be enough info for the developer to
either file a bug w/ a plugin author to update or fork it to fix to
their needs.


On Thu, Mar 14, 2013 at 8:23 PM, Filip Maj <fil@adobe.com> wrote:
> I agree. This is not a problem worth solving (if you have ever worked with
> Ruby gems, you know what I'm talking about)
>
> And the plugin-depending-on-a-plugin is already happening. Some plugins
> require Facebook Connect already.. IMO drawing a line in the sand here is
> a good first step.
>
> On 3/14/13 12:18 PM, "Braden Shepherdson" <braden@chromium.org> wrote:
>
>>Even if we can do something clever with the code for those two versions of
>>a plugin, the exec call names are still in one namespace.
>>
>>Adding versions to them would, in my opinion, make the cure worse than the
>>disease. Then a plugin author would have to update his code every time any
>>of his dependencies updated. Then all of his downstream users have to
>>update themselves, and so on up the tree.
>>
>>Braden
>>
>>
>>On Thu, Mar 14, 2013 at 3:01 PM, Lorin Beer
>><lorin.beer.dev@gmail.com>wrote:
>>
>>> >Cordova versions: we have <engine> tags. A single cordova project is
>>> >stuck to a single cordova version. Attempting to install a plugin into
>>>a
>>> >project running a different version of cordova should fail. Simple as
>>> that.
>>>
>>> I'm more comfortable with a warning. While warnings are often
>>>(re:always)
>>> ignored by developers, a cordova-plugin wouldn't necessarily be a
>>> guaranteed runtime fail. Forcing one seems unnecessarily prohibitive.
>>>
>>> > Plugin versions: since each cordova project is its own enclosed
>>> >namespace, we can't allow for this either. You install Plugin A, it
>>>needs
>>> >plugin B, so plugin B gets installed along the way. You try to install
>>> > Plugin C, plugman realizes that two different versions of Plugin B are
>>> > then required (and colliding), and so we should fail at this point.
>>>
>>> agreed on this point, however is this a class of problem (interwoven
>>>plugin
>>> dependency) which we currently see? How many users is this sort of issue
>>> likely to affect? Having a forced fail at this point strikes me as
>>> justified.
>>>
>>>
>>> This may be naive to how plugins are currently handled, but is there no
>>> tractable way of providing a 'namespace' for plugins, allowing multiple
>>> versions of the same plugin to run simultaneously? A 'plugin version'
>>> qualifier, rather than, as Braden put it, "these classes need to go
>>>into a
>>> single global namespace that's getting called by the bridge."
>>>
>>>
>>> On Thu, Mar 14, 2013 at 11:20 AM, Filip Maj <fil@adobe.com> wrote:
>>>
>>> > Sounds good to me Anis. More comments inline below.
>>> >
>>> > On 3/14/13 10:47 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>> >
>>> > >The hard stuff is dealing with
>>> > >plugin versions, dependencies and Cordova versions.
>>> >
>>> > If we think of these problems in light of a single cordova project, I
>>> > think it gets easier because:
>>> >
>>> > - Cordova versions: we have <engine> tags. A single cordova project
is
>>> > stuck to a single cordova version. Attempting to install a plugin
>>>into a
>>> > project running a different version of cordova should fail. Simple as
>>> that.
>>> >
>>> > >Example: Plugin A depends on version 0.1.0 of Plugin B and Plugin C
>>> > >depends
>>> > >on version 0.2.0 of plugin B.
>>> >
>>> > - Plugin versions: since each cordova project is its own enclosed
>>> > namespace, we can't allow for this either. You install Plugin A, it
>>>needs
>>> > plugin B, so plugin B gets installed along the way. You try to install
>>> > Plugin C, plugman realizes that two different versions of Plugin B are
>>> > then required (and colliding), and so we should fail at this point.
>>> >
>>> > >
>>> > >That is also assuming that whatever plugin we install that requires
a
>>> > >specific Cordova version, its dependencies will also work with that
>>>same
>>> > >Cordova version (<engine> tag).
>>> > >
>>> > >I don't know if we will have this scenario ever but this is one of
>>>the
>>> > >nightmares of package management.
>>> > >
>>> > >We can solve that problem once we hit it. For now we only need to
>>>know
>>> > >what
>>> > >plugins are installed and how to uninstall them.
>>> > >
>>> > >so a simple structure like this could work to start:
>>> > >
>>> > >PROJECT/.plugins/BarcodeScanner/plugin.xml
>>> > >PROJECT/.plugins/Facebook-Connect/plugin.xml
>>> > >...
>>> > >
>>> > ></braindump>
>>> > >
>>> > >-a
>>> > >
>>> > >On Thu, Mar 14, 2013 at 10:33 AM, Andrew Grieve
>>> > ><agrieve@chromium.org>wrote:
>>> > >
>>> > >> Copying the plugin.xml into the platform's project somewhere sounds
>>> > >>like a
>>> > >> good idea to me.
>>> > >>
>>> > >> I don't think we'd need to look in the config.xml to see what's
>>> > >>installed
>>> > >> then. We can just look at what plugin.xml files exist.
>>> > >>
>>> > >>
>>> > >> On Thu, Mar 14, 2013 at 12:15 PM, Filip Maj <fil@adobe.com>
wrote:
>>> > >>
>>> > >> > I'm wary of creating an additional manifest..
>>> > >> >
>>> > >> > What if we came up with a convention for storing each plugin's
>>> > >>plugin.xml
>>> > >> > within the native project structure that the plugin got installed
>>> > >>into?
>>> > >> It
>>> > >> > IS extra space needed, but a few kb per plugin doesn't seem
so
>>>bad
>>> > >>(this
>>> > >> > is just my naïve first-pass type of brainstorming for this
stuff)
>>> > >> >
>>> > >> > I see a few benefits:
>>> > >> >
>>> > >> > - Can then use <plugin> or <feature> tags inside
the config.xml
>>>to
>>> > >> > determine which plugins are installed
>>> > >> > - Can trace back to the plugin's plugin.xml file based on
the
>>>name
>>> > >>and/or
>>> > >> > value in these tags (based on whatever convention we come
up with
>>> > >>storing
>>> > >> > the .xml file, as I suggested above). This way on each plugin
>>> install
>>> > >>or
>>> > >> > removal, we can detect collisions.
>>> > >> > - can use plugman on its own on a per-project basis
>>> > >> > - since we can go from config.xml -> all the plugin.xmls,
this
>>>gives
>>> > >>us a
>>> > >> > start at dependency management
>>> > >> >
>>> > >> > Let's keep this train going! I feel we're getting somewhere
here
>>> > >> >
>>> > >> > On 3/14/13 7:35 AM, "Braden Shepherdson" <braden@chromium.org>
>>> wrote:
>>> > >> >
>>> > >> > >I'm working on a high-level what-not-how sort of document
for
>>>the
>>> > >>whole
>>> > >> > >plugin tools story, and this is something I keep coming
back to.
>>> It's
>>> > >> > >looking like we'll need to know what plugins are installed
and
>>> where
>>> > >> files
>>> > >> > >have been placed where. This is important for uninstalling
and
>>>also
>>> > >>for
>>> > >> > >updating the iOS project files.
>>> > >> > >
>>> > >> > >If we do need a manifest of that kind, it should absolutely
be a
>>> > >>shared
>>> > >> > >format between plugman and cordova-cli. Or perhaps more
>>>precisely,
>>> > >>for
>>> > >> > >anything dealing at the level of files, cordova-cli should
be
>>> calling
>>> > >> > >plugman, which would deal with the files and update the
>>>manifest.
>>> I'm
>>> > >> not
>>> > >> > >thrilled about having such metadata, but it's hard to
use the
>>> > >>filesystem
>>> > >> > >as
>>> > >> > >the source of truth here.
>>> > >> > >
>>> > >> > >Thoughts?
>>> > >> > >
>>> > >> > >Braden
>>> > >> > >
>>> > >> > >
>>> > >> > >On Thu, Mar 14, 2013 at 3:21 AM, Filip Maj <fil@adobe.com>
>>>wrote:
>>> > >> > >
>>> > >> > >> On 3/12/13 5:26 PM, "Andrew Grieve" <agrieve@chromium.org>
>>> wrote:
>>> > >> > >>
>>> > >> > >> >One possible solution: Have JS-only plugins add
a <plugin>
>>>tag
>>> > >>with a
>>> > >> > >>name
>>> > >> > >> >but no value.
>>> > >> > >>
>>> > >> > >> Thinking more generally here, as Anis said, the problem
here
>>>is
>>> > >> > >> dependencies. I think determining how aware plugman
needs to
>>>be
>>> of
>>> > >>the
>>> > >> > >> project is important. Pretty sure plugman needs to:
>>> > >> > >>
>>> > >> > >> A) know which plugins are installed
>>> > >> > >> B) able to get a reference to each plugin's config
file, to be
>>> > >>able to
>>> > >> > >> warn of things like collisions
>>> > >> > >>
>>> > >> > >> Does this sound right?
>>> > >> > >>
>>> > >> > >>
>>> > >> >
>>> > >> >
>>> > >>
>>> >
>>> >
>>>
>

Mime
View raw message