cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: A word about plugins
Date Thu, 14 Mar 2013 19:18:37 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message