cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: <plugins> tag, and accessing the plugin list
Date Thu, 14 Nov 2013 19:56:19 GMT
Please do, maybe break down in bullet form in the config thread.


On Thu, Nov 14, 2013 at 11:47 AM, Braden Shepherdson <braden@chromium.org>wrote:

> Brian, I think you're a bit confused about which information is in what
> files. I can break that down here if people would find it valuable.
>
> That timing works for me, Anis. I'll see you, and any other interested
> parties, there and then. If you're not Anis, add +Braden Shepherdson ahead
> of time and I'll make sure you get added into the Hangout.
>
> Braden
>
>
> On Thu, Nov 14, 2013 at 2:36 PM, Brian LeRoux <b@brian.io> wrote:
>
> > This is helpful. I think my impedance mismatch here is how we ended up
> with
> > plugin.xml information (bridge mappings) in a user config file while ID
> and
> > VERSION ended up in a generated file. I know we aren't interested in
> > changing stuff that already works but I like to fully understand where we
> > are at. In any case, throwing this in an already generated file makes
> > perfect sense for this particular case. For some reason I thought we were
> > proposing another new config file which, hopefully, does not become
> > necessary.
> >
> > In other words: +1
> >
> > (This said, I would like to keep rolling on the other config file
> > discussion to see if it is possible to consolidate that mess into
> something
> > more maintainable.)
> >
> >
> >
> > On Thu, Nov 14, 2013 at 10:44 AM, Andrew Grieve <agrieve@chromium.org
> > >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.
> > >
> > > Using config.xml:
> > >  - It doesn't have the information that we need
> > >  - This is always loaded by native sides, so it's a nice fit.
> > >
> > > Using <feature>:
> > >  - These are for defining Bridge channels
> > >  - Plugins define 0 or more of these
> > >  - Adding empty ones for plugins that don't define them causes
> exceptions
> > > in the native layer. We'd like this change to not break older versions
> of
> > > cordova.
> > >
> > > So, although it seems like <feature> would make sense, we've already
> used
> > > <feature> to mean something else (bridge channels).
> > >
> > > I think Braden's suggestion of adding a new tag is the simplest, both
> > > implementation-wise, as well as semantically (it has a single,
> > well-defined
> > > purpose). What I especially like about it, is that it separates which
> > tags
> > > are written by plugin devs (<feature>) from tags that are generated by
> > > plugman (<cordova-plugin>)
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Nov 14, 2013 at 1:40 PM, Brian LeRoux <b@brian.io> wrote:
> > >
> > > > Ok, everybody be calm. We are adults and we are capable of working
> > > through
> > > > this in a dispassionate manner and has nothing to do with you, your
> > code,
> > > > or whatever. We all just want to find the best solution. Blankets
> > > > statements like 'more hacky code' does no good. Let's just stick to
> > > factual
> > > > stuff and stay away from subjective identification. Ok?
> > > >
> > > > "as to leaking into userland, these <feature> tags are relevant to
> > plugin
> > > > developers" ... so would this particular information belong to
> > > > plugin.xml????
> > > >
> > > > Also, Joe had a good question earlier. Despite all this problem
> > solving I
> > > > have no idea what the actual problem is we are trying to solve. We
> have
> > > > lots of solutions but what precisely do our users gain from runtime
> > > > introspection here?
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson <
> > > braden@chromium.org
> > > > >wrote:
> > > >
> > > > > Brian, as to leaking into userland, these <feature> tags are
> relevant
> > > to
> > > > > plugin developers, since they have to define the mapping of exec
> > names
> > > to
> > > > > native files so we can load their plugins. None of this is visible
> to
> > > app
> > > > > developers or end users.
> > > > >
> > > > > We're not paying by the byte, or the top-level tag, in config.xml.
> NB
> > > > that
> > > > > this is the platform config.xml, the one that's a build artifact no
> > one
> > > > but
> > > > > the platform code is ever supposed to look at. Why are we sweating
> so
> > > > hard
> > > > > over adding some new information into the file, and trying to
> > shoehorn
> > > it
> > > > > into existing tags? The code to handle this is simpler in Plugman
> and
> > > on
> > > > > the platforms to have this be a separate tag, rather than mixing it
> > in
> > > > with
> > > > > <feature>.
> > > > >
> > > > > If we want to use <feature> tags for this, despite it requiring
> more,
> > > and
> > > > > more hacky, code all around, we're going to need a good reason. I
> > > haven't
> > > > > heard any reason for why using <feature> gains us anything.
> > > > >
> > > > > Carlos, as I noted in my remixed proposal above, I originally
> wanted
> > to
> > > > use
> > > > > cordova_plugins.js or a similar www/ file for this, but there are
> > > > problems
> > > > > with that. On the other hand, I would much rather add a new file
> that
> > > can
> > > > > be loaded as a js-module than do this using hacked-up <feature>
> tags.
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Thu, Nov 14, 2013 at 12:50 PM, Don Coleman <
> don.coleman@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > JavaScript only plugin implementations are valid on BlackBerry
> 10.
> > > Some
> > > > > > things that require native code on Android can be implemented in
> > > client
> > > > > > side JavaScript on BlackBerry using com.blackberry.invoke.
> > > > > >
> > > > > >
> > > > > > On Thu, Nov 14, 2013 at 12:26 PM, Joe Bowser <bowserj@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > On Thu, Nov 14, 2013 at 9:12 AM, Brian LeRoux <b@brian.io>
> > wrote:
> > > > > > > > First thing: might as well give up on referencing config.xml
> > as a
> > > > > > > standard.
> > > > > > > > That's a historical footnote of little relevance anymore!
> > > > > > > >
> > > > > > > > It feels leaky to define the mapping in <feature>. Would seem
> > to
> > > me
> > > > > > that
> > > > > > > > <feature> is a userland thing from a user perspective I want
> to
> > > > know
> > > > > > > about
> > > > > > > > the ID and VERSION and the guts of what happens under the
> hood
> > is
> > > > > none
> > > > > > of
> > > > > > > > business. No?
> > > > > > > >
> > > > > > >
> > > > > > > This is actually where the mapping happens right now, and I
> > really
> > > > > > > don't want to change this, since changing mapping would break
> > > > > > > EVERYTHING.  That being said, I don't know why we can't have
> > > feature
> > > > > > > tags with no *-package params.  That being said, I'm not sure
> > what
> > > > the
> > > > > > > point would even be, since JS-only plugins aren't really
> plugins
> > at
> > > > > > > all and are just Javascript libraries.  Are there current
> > examples
> > > of
> > > > > > > this in Cordova currently?
> > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Nov 14, 2013 at 8:32 AM, Braden Shepherdson <
> > > > > > braden@chromium.org
> > > > > > > >wrote:
> > > > > > > >
> > > > > > > >> I'm going to try to summarize some points so we can get on
> the
> > > > same
> > > > > > > page.
> > > > > > > >>
> > > > > > > >> tl;dr: see the last two paragraphs for what I'm actually
> > > > proposing.
> > > > > > > >>
> > > > > > > >> First, background on why we have <feature> tags. They map a
> > > bridge
> > > > > > name
> > > > > > > >> (eg. "FileTransfer" on all platforms) used with
> cordova.exec()
> > > to
> > > > > the
> > > > > > > >> native code module that implements the plugin (eg.
> > > > > > > >> "org.apache.cordova.filetransfer.FileTransfer" on Android,
> > > > > > > >> "CDVFileTransfer" on iOS, etc.). The native side of the
> bridge
> > > > uses
> > > > > > this
> > > > > > > >> information to load and call the right plugin's
> implementation
> > > > > after a
> > > > > > > >> cordova.exec() call.
> > > > > > > >>
> > > > > > > >> Note that a plugin can define 0 or more <feature> tags.
> > Plugins
> > > > with
> > > > > > no
> > > > > > > >> native code won't have one. In principle, a plugin can have
> > more
> > > > > than
> > > > > > > one,
> > > > > > > >> though we can't think of any examples of that.
> > > > > > > >>
> > > > > > > >> When I first looked at this problem of wanting to know, at
> > > > runtime,
> > > > > > what
> > > > > > > >> plugins are installed, I originally considered using
> > > > > > cordova_plugins.js
> > > > > > > to
> > > > > > > >> learn the information. There are two problems here. One, the
> > > file
> > > > > > > doesn't
> > > > > > > >> include information about plugin id and version. We could
> add
> > > it,
> > > > > but
> > > > > > > the
> > > > > > > >> second problem is that cordova_plugins.js maps <js-module>
> > names
> > > > > (used
> > > > > > > with
> > > > > > > >> cordova.require()) to file names. Here again any one plugin
> > can
> > > > > have 0
> > > > > > > or
> > > > > > > >> more <js-modules>; many have several.
> > > > > > > >>
> > > > > > > >> I then considered using the <feature> tags. The same
> problems
> > > > apply
> > > > > > > here:
> > > > > > > >> they don't map 1-1, and don't have the data we need.
> > > > > > > >>
> > > > > > > >> Others in the thread have proposed adding this data to the
> > > > <feature>
> > > > > > > tags,
> > > > > > > >> and adding <feature> tags automatically for plugins that
> don't
> > > > > already
> > > > > > > have
> > > > > > > >> one (or alternatively, adding a new, autogenerated <feature>
> > for
> > > > > every
> > > > > > > >> plugin). The problem here is that the various native
> platforms
> > > are
> > > > > > > >> expecting each <feature> to define a bridge name -> native
> > code
> > > > > module
> > > > > > > >> mapping, and these new ones won't do so. This is a
> potentially
> > > > > > > >> bug-introducing change, because we'll have to make sure
> every
> > > > > platform
> > > > > > > can
> > > > > > > >> handle these new tags which aren't like the old ones.
> > > > > > > >>
> > > > > > > >> All of this led to my original proposal: add a new top-level
> > > tag,
> > > > > > > >> <plugins>, whose children are exactly one <plugin id="..."
> > > > > > > version="..." />
> > > > > > > >> for every plugin installed on this platform. We would then
> > have
> > > > two
> > > > > > > >> separate lists in config.xml, but they are listing different
> > > > things
> > > > > > > (bridge
> > > > > > > >> mappings vs. plugins) for different purposes. Since this is
> an
> > > > > > addition,
> > > > > > > >> the platforms that don't support the new tag will just
> ignore
> > it
> > > > > > safely.
> > > > > > > >>
> > > > > > > >> I realize that the top-level <plugins> tag is something we
> had
> > > > > > > previously,
> > > > > > > >> before moving to the W3C <widget> spec's <feature> tags
> > instead.
> > > > I'm
> > > > > > > >> perfectly willing to change the name, to perhaps
> > > > > <installed-plugins>,
> > > > > > to
> > > > > > > >> avoid any confusion with the old <plugins> tag. Any better
> > > > > suggestions
> > > > > > > for
> > > > > > > >> the names?
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Braden
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> On Wed, Nov 13, 2013 at 7:25 PM, Shazron <shazron@gmail.com
> >
> > > > wrote:
> > > > > > > >>
> > > > > > > >> > Didn't recommend anything. Just seeing how the impact is.
> > > Didn't
> > > > > > > think of
> > > > > > > >> > the native bits (the native code that has some js that
> they
> > > call
> > > > > > into)
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > On Wed, Nov 13, 2013 at 3:43 PM, Jesse <
> > > purplecabbage@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > >> >
> > > > > > > >> > > Currently installing the plugin
> org.apache.cordova.device
> > > will
> > > > > > add a
> > > > > > > >> > > different feature tag for each platform/project's
> > > config.xml.
> > > > > > > >> > > <!-- firefoxos -->
> > > > > > > >> > > <feature name="Device">
> > > > > > > >> > > <param name="firefoxos-package" value="Device" />
> > > > > > > >> > > </feature>
> > > > > > > >> > >
> > > > > > > >> > > <!-- android -->
> > > > > > > >> > > <feature name="Device" >
> > > > > > > >> > > <param name="android-package"
> > > > > > > >> value="org.apache.cordova.device.Device"/>
> > > > > > > >> > > </feature>
> > > > > > > >> > >
> > > > > > > >> > > <!-- ios -->
> > > > > > > >> > > <feature name="Device">
> > > > > > > >> > > <param name="ios-package" value="CDVDevice"/>
> > > > > > > >> > > </feature>
> > > > > > > >> > >
> > > > > > > >> > > <!-- blackberry -->
> > > > > > > >> > > <feature name="Device" value="Device"/>
> > > > > > > >> > > <!-- wp7 and wp8 -->
> > > > > > > >> > > <feature name="Device">
> > > > > > > >> > > <param name="wp-package" value="Device"/>
> > > > > > > >> > > </feature>
> > > > > > > >> > >
> > > > > > > >> > > Also, presumably, the following can be used on ALL
> without
> > > > > > conflict:
> > > > > > > >> > >
> > > > > > > >> > > <feature name="Device" value="Device">
> > > > > > > >> > > <param name="firefoxos-package" value="Device" />
> > > > > > > >> > > <param name="android-package"
> > > > > > > >> value="org.apache.cordova.device.Device"/>
> > > > > > > >> > > <param name="ios-package" value="CDVDevice"/>
> > > > > > > >> > > <param name="wp-package" value="Device"/>
> > > > > > > >> > > </feature>
> > > > > > > >> > >
> > > > > > > >> > > It would be nice if blackberry supported the
> > > > feature/param@name
> > > > > > > >> > > ='bb-package'
> > > > > > > >> > > but I don't think this is imperative.
> > > > > > > >> > >
> > > > > > > >> > > We are missing a couple points from Braden:
> > > > > > > >> > > a) js only plugins do not have config.xml entries
> > > > > > > >> > > b) one plugin may add multiple features ( not sure if
> this
> > > has
> > > > > > ever
> > > > > > > >> > > happened in practice, it may be easier to just force the
> > > > plugin
> > > > > > > >> developer
> > > > > > > >> > > to make their class have a single point of contact in
> the
> > > > > features
> > > > > > > >> list,
> > > > > > > >> > > and delegate in their own code. )
> > > > > > > >> > >
> > > > > > > >> > > Shaz's recommendations break everything everywhere from
> > > what I
> > > > > can
> > > > > > > >> tell.
> > > > > > > >> > > This would require changes to all existing plugins, AND
> > all
> > > > > > platform
> > > > > > > >> > > bridges native bits, and cordova-js. I don't think we
> want
> > > to
> > > > be
> > > > > > > this
> > > > > > > >> > > destructive.
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > @purplecabbage
> > > > > > > >> > > risingj.com
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Nov 13, 2013 at 3:11 PM, Shazron <
> > shazron@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >> > >
> > > > > > > >> > > > Let's see the impact of using ID as name
> > > > > > > >> > > >
> > > > > > > >> > > > 1. plugin.xml feature tag, name attribute -> change
> the
> > > > value
> > > > > to
> > > > > > > the
> > > > > > > >> > > plugin
> > > > > > > >> > > > id. Or just remove the attribute, plugman can inject
> the
> > > > > plugin
> > > > > > id
> > > > > > > >> > > > automatically(?) so it is less error-prone - not sure
> > > > > > > >> > > > 2. plugin's js -> change all service names to ID in
> > > > > cordova.exec
> > > > > > > >> > > >
> > > > > > > >> > > > For user upgrades, they would remove the old plugin,
> > then
> > > > add
> > > > > > the
> > > > > > > new
> > > > > > > >> > > one -
> > > > > > > >> > > > so it's relatively painless I think.
> > > > > > > >> > > >
> > > > > > > >> > > >
> > > > > > > >> > > > On Wed, Nov 13, 2013 at 2:47 PM, Brian LeRoux <
> > b@brian.io
> > > >
> > > > > > wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > > so would it be insane to deprecate the name thing
> and
> > > just
> > > > > go
> > > > > > > ID?
> > > > > > > >> > > > >
> > > > > > > >> > > > > (Warning: I am insane.)
> > > > > > > >> > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > > On Wed, Nov 13, 2013 at 2:39 PM, Shazron Abdullah <
> > > > > > > shaz@adobe.com>
> > > > > > > >> > > > wrote:
> > > > > > > >> > > > >
> > > > > > > >> > > > > > Brian: plugin mapping "service js name" ->
> "service
> > > > native
> > > > > > > >> > > name/class"
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > On 11/13/13 2:36 PM, "Brian LeRoux" <b@brian.io>
> > > wrote:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > >what are we using <feature> for?
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > >On Wed, Nov 13, 2013 at 2:27 PM, Braden
> Shepherdson
> > > > > > > >> > > > > > ><braden@google.com>wrote:
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > >> My concern with (ab)using feature tags for this
> > is
> > > > that
> > > > > > now
> > > > > > > >> > > > platforms
> > > > > > > >> > > > > > >>that
> > > > > > > >> > > > > > >> don't know about these parameters, and
> especially
> > > > about
> > > > > > the
> > > > > > > >> > dummy
> > > > > > > >> > > > ones
> > > > > > > >> > > > > > >>for
> > > > > > > >> > > > > > >> js-only plugins, have a bug, rather than a
> > missing
> > > > > > feature.
> > > > > > > >> > > > > > >> On Nov 13, 2013 4:40 PM, "Gorkem Ercan" <
> > > > > > > >> gorkem.ercan@gmail.com
> > > > > > > >> > >
> > > > > > > >> > > > > wrote:
> > > > > > > >> > > > > > >>
> > > > > > > >> > > > > > >> > If a plugin does not inject a feature tag for
> > > some
> > > > > > > reason it
> > > > > > > >> > is
> > > > > > > >> > > > the
> > > > > > > >> > > > > > >>same
> > > > > > > >> > > > > > >> > deal as before. Plugman injects one with the
> id
> > > and
> > > > > > > version
> > > > > > > >> as
> > > > > > > >> > > > > params.
> > > > > > > >> > > > > > >> > If a plugin has multiple feature tags since
> > they
> > > > will
> > > > > > > have
> > > > > > > >> the
> > > > > > > >> > > > same
> > > > > > > >> > > > > > >> plugin
> > > > > > > >> > > > > > >> > id and version you will still be able to
> > > introspect
> > > > > the
> > > > > > > >> plugin
> > > > > > > >> > > id
> > > > > > > >> > > > > and
> > > > > > > >> > > > > > >> > version.
> > > > > > > >> > > > > > >> >
> > > > > > > >> > > > > > >> > And apparently adobe sf just had a coffee
> > > break...
> > > > > > > >> > > > > > >> > --
> > > > > > > >> > > > > > >> > Gorkem
> > > > > > > >> > > > > > >> >
> > > > > > > >> > > > > > >> >
> > > > > > > >> > > > > > >> > On Wed, Nov 13, 2013 at 4:27 PM, Braden
> > > Shepherdson
> > > > > > > >> > > > > > >><braden@chromium.org
> > > > > > > >> > > > > > >> > >wrote:
> > > > > > > >> > > > > > >> >
> > > > > > > >> > > > > > >> > > I'm open to changing the names to something
> > > else,
> > > > > > > since I
> > > > > > > >> > > > realize
> > > > > > > >> > > > > > >>there
> > > > > > > >> > > > > > >> > > used to be a <plugins> tag and <plugin>
> tags
> > > > > inside,
> > > > > > > >> before
> > > > > > > >> > we
> > > > > > > >> > > > > used
> > > > > > > >> > > > > > >> > > <feature>.
> > > > > > > >> > > > > > >> > >
> > > > > > > >> > > > > > >> > > Adding these as parameters on the <feature>
> > > tags
> > > > is
> > > > > > not
> > > > > > > >> > > enough,
> > > > > > > >> > > > > > >>because
> > > > > > > >> > > > > > >> > the
> > > > > > > >> > > > > > >> > > <feature> tags correspond to "names the
> > bridge
> > > > > knows
> > > > > > > >> about",
> > > > > > > >> > > > which
> > > > > > > >> > > > > > >>is
> > > > > > > >> > > > > > >> not
> > > > > > > >> > > > > > >> > > quite "plugins". JS-only plugins don't
> appear
> > > > here,
> > > > > > > and a
> > > > > > > >> > > single
> > > > > > > >> > > > > > >>plugin
> > > > > > > >> > > > > > >> > can
> > > > > > > >> > > > > > >> > > have multiple bridge names pointing at
> > > different
> > > > > > > classes.
> > > > > > > >> > > > > > >> > >
> > > > > > > >> > > > > > >> > > Braden
> > > > > > > >> > > > > > >> > >
> > > > > > > >> > > > > > >> > >
> > > > > > > >> > > > > > >> > > On Wed, Nov 13, 2013 at 4:25 PM, Gorkem
> Ercan
> > > > > > > >> > > > > > >><gorkem.ercan@gmail.com
> > > > > > > >> > > > > > >> > > >wrote:
> > > > > > > >> > > > > > >> > >
> > > > > > > >> > > > > > >> > > > It is unfortunate that the name attribute
> > on
> > > > the
> > > > > > > feature
> > > > > > > >> > tag
> > > > > > > >> > > > is
> > > > > > > >> > > > > > >>not
> > > > > > > >> > > > > > >> the
> > > > > > > >> > > > > > >> > > > plugin id but a name. The uniqueness of
> the
> > > > name
> > > > > is
> > > > > > > not
> > > > > > > >> > > > > > >>guaranteed by
> > > > > > > >> > > > > > >> > > > plugman so I can imagine this causing
> > > problems
> > > > in
> > > > > > the
> > > > > > > >> > > future.
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > > > I can see the need for the tag but I am
> not
> > > > sure
> > > > > id
> > > > > > > >> > <plugin>
> > > > > > > >> > > > tag
> > > > > > > >> > > > > > >>is
> > > > > > > >> > > > > > >> the
> > > > > > > >> > > > > > >> > > > correct approach. There are plugins out
> > there
> > > > > that
> > > > > > > are
> > > > > > > >> > still
> > > > > > > >> > > > > using
> > > > > > > >> > > > > > >> that
> > > > > > > >> > > > > > >> > > tag
> > > > > > > >> > > > > > >> > > > for instance [1] is from barcode scanner
> > > plugin
> > > > > > from
> > > > > > > the
> > > > > > > >> > > > > > >>registry. As
> > > > > > > >> > > > > > >> > an
> > > > > > > >> > > > > > >> > > > alternate, <feature> tag can be used and
> id
> > > and
> > > > > > > version
> > > > > > > >> > info
> > > > > > > >> > > > can
> > > > > > > >> > > > > > >>be
> > > > > > > >> > > > > > >> > > > injected as additional <param> tags by
> > > plugman.
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > > > [1]   <config-file
> > > target="res/xml/plugins.xml"
> > > > > > > >> > > > > parent="/plugins">
> > > > > > > >> > > > > > >> > > >             <plugin name="BarcodeScanner"
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> >
> value="com.phonegap.plugins.barcodescanner.BarcodeScanner"/>
> > > > > > > >> > > > > > >> > > >         </config-file>
> > > > > > > >> > > > > > >> > > > --
> > > > > > > >> > > > > > >> > > > Gorkem
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > > > On Wed, Nov 13, 2013 at 3:23 PM, Braden
> > > > > > Shepherdson <
> > > > > > > >> > > > > > >> > braden@chromium.org
> > > > > > > >> > > > > > >> > > > >wrote:
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > > > > The <feature> tags list only those
> > plugins
> > > > > which
> > > > > > > are
> > > > > > > >> > > > relevant
> > > > > > > >> > > > > to
> > > > > > > >> > > > > > >> the
> > > > > > > >> > > > > > >> > > > > bridge. Also they map from exec bridge
> > name
> > > > to
> > > > > > > native
> > > > > > > >> > code
> > > > > > > >> > > > > class
> > > > > > > >> > > > > > >> > name,
> > > > > > > >> > > > > > >> > > > and
> > > > > > > >> > > > > > >> > > > > have no information about which plugin
> > > > they're
> > > > > > > from,
> > > > > > > >> or
> > > > > > > >> > > that
> > > > > > > >> > > > > > >> plugin's
> > > > > > > >> > > > > > >> > > id
> > > > > > > >> > > > > > >> > > > or
> > > > > > > >> > > > > > >> > > > > version.
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > > > As to multiple platforms, there are
> > several
> > > > > > reasons
> > > > > > > >> why
> > > > > > > >> > > I'm
> > > > > > > >> > > > > > >> unlikely
> > > > > > > >> > > > > > >> > to
> > > > > > > >> > > > > > >> > > > add
> > > > > > > >> > > > > > >> > > > > this feature to platforms other than
> iOS
> > or
> > > > > > > Android.
> > > > > > > >> > > First,
> > > > > > > >> > > > > I'm
> > > > > > > >> > > > > > >>not
> > > > > > > >> > > > > > >> > set
> > > > > > > >> > > > > > >> > > > up
> > > > > > > >> > > > > > >> > > > > for development on any of the others.
> > This
> > > is
> > > > > > > >> especially
> > > > > > > >> > > > true
> > > > > > > >> > > > > of
> > > > > > > >> > > > > > >> the
> > > > > > > >> > > > > > >> > > ones
> > > > > > > >> > > > > > >> > > > > that can't be built on Mac, especially
> > > > Windows
> > > > > > > >> (Phone).
> > > > > > > >> > > > > Second,
> > > > > > > >> > > > > > >>I
> > > > > > > >> > > > > > >> > don't
> > > > > > > >> > > > > > >> > > > > know anything about developing on those
> > > > > > platforms:
> > > > > > > I
> > > > > > > >> > don't
> > > > > > > >> > > > > know
> > > > > > > >> > > > > > >>the
> > > > > > > >> > > > > > >> > > > > libraries or tools (or C# for Windows
> et
> > > al).
> > > > > > > Third,
> > > > > > > >> > what
> > > > > > > >> > > > I'm
> > > > > > > >> > > > > > >> > > ultimately
> > > > > > > >> > > > > > >> > > > > working on is getting the App Harness
> > > working
> > > > > > > nicely
> > > > > > > >> as
> > > > > > > >> > a
> > > > > > > >> > > > > > >>launcher
> > > > > > > >> > > > > > >> > and
> > > > > > > >> > > > > > >> > > > > testbed for mobile Chrome apps, which
> > only
> > > > > > support
> > > > > > > iOS
> > > > > > > >> > and
> > > > > > > >> > > > > > >>Android
> > > > > > > >> > > > > > >> > > > anyway.
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > > > I agree the platforms should strive for
> > > > > > > consistency,
> > > > > > > >> but
> > > > > > > >> > > any
> > > > > > > >> > > > > new
> > > > > > > >> > > > > > >> > > features
> > > > > > > >> > > > > > >> > > > > have to start somewhere. This is a
> pretty
> > > > > > > >> > straightforward
> > > > > > > >> > > > > > >> > > implementation,
> > > > > > > >> > > > > > >> > > > > and with my work on Android and iOS as
> a
> > > > > > > reference, it
> > > > > > > >> > > > should
> > > > > > > >> > > > > be
> > > > > > > >> > > > > > >> > quick
> > > > > > > >> > > > > > >> > > to
> > > > > > > >> > > > > > >> > > > > add to other platforms.
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > > > Braden
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > > > On Wed, Nov 13, 2013 at 2:54 PM, Jesse
> <
> > > > > > > >> > > > > purplecabbage@gmail.com
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > > >> > > wrote:
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > > > > Adding this to iOS and Android only
> is
> > > kind
> > > > > of
> > > > > > > mean.
> > > > > > > >> > >  What
> > > > > > > >> > > > > > >>ends
> > > > > > > >> > > > > > >> up
> > > > > > > >> > > > > > >> > > > > > happening is the high profile
> platforms
> > > > (ie.
> > > > > > the
> > > > > > > >> ones
> > > > > > > >> > > that
> > > > > > > >> > > > > get
> > > > > > > >> > > > > > >> ALL
> > > > > > > >> > > > > > >> > > the
> > > > > > > >> > > > > > >> > > > > > attention) get a new feature and the
> > > others
> > > > > > > 'appear'
> > > > > > > >> > to
> > > > > > > >> > > be
> > > > > > > >> > > > > > >> behind.
> > > > > > > >> > > > > > >> >  I
> > > > > > > >> > > > > > >> > > > > think
> > > > > > > >> > > > > > >> > > > > > we should focus on remaining
> consistent
> > > to
> > > > > some
> > > > > > > >> > degree,
> > > > > > > >> > > > > > >>otherwise
> > > > > > > >> > > > > > >> > you
> > > > > > > >> > > > > > >> > > > end
> > > > > > > >> > > > > > >> > > > > > up just making more work for the
> other
> > > > > platform
> > > > > > > >> > > > developers.
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > > This does not seem like it would be
> > hard
> > > > for
> > > > > > you
> > > > > > > to
> > > > > > > >> > > > > implement
> > > > > > > >> > > > > > >>on
> > > > > > > >> > > > > > >> > > > windows
> > > > > > > >> > > > > > >> > > > > > phone and blackberry as well, and
> > having
> > > > you
> > > > > > > spend a
> > > > > > > >> > few
> > > > > > > >> > > > > > >>minutes
> > > > > > > >> > > > > > >> in
> > > > > > > >> > > > > > >> > > > those
> > > > > > > >> > > > > > >> > > > > > platforms would probably be a good
> > thing
> > > > > > anyway.
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > > I too am also not sure why the
> existing
> > > > > feature
> > > > > > > tag
> > > > > > > >> in
> > > > > > > >> > > > > > >>config.xml
> > > > > > > >> > > > > > >> > is
> > > > > > > >> > > > > > >> > > > not
> > > > > > > >> > > > > > >> > > > > > enough.
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > > @purplecabbage
> > > > > > > >> > > > > > >> > > > > > risingj.com
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > > On Wed, Nov 13, 2013 at 11:38 AM,
> > Gorkem
> > > > > Ercan
> > > > > > <
> > > > > > > >> > > > > > >> > > gorkem.ercan@gmail.com
> > > > > > > >> > > > > > >> > > > > > >wrote:
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > > > > Hey Braden,
> > > > > > > >> > > > > > >> > > > > > > Why is not the current <feature>
> tags
> > > > > > > sufficient
> > > > > > > >> for
> > > > > > > >> > > > this?
> > > > > > > >> > > > > > >> > > > > > > --
> > > > > > > >> > > > > > >> > > > > > > Gorkem
> > > > > > > >> > > > > > >> > > > > > >
> > > > > > > >> > > > > > >> > > > > > >
> > > > > > > >> > > > > > >> > > > > > > On Wed, Nov 13, 2013 at 2:32 PM,
> > Braden
> > > > > > > >> Shepherdson
> > > > > > > >> > <
> > > > > > > >> > > > > > >> > > > > braden@chromium.org
> > > > > > > >> > > > > > >> > > > > > > >wrote:
> > > > > > > >> > > > > > >> > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > Hey folks,
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > We've been kicking around the
> idea
> > of
> > > > > > > getting at
> > > > > > > >> > > which
> > > > > > > >> > > > > > >> > > > > plugins/versions
> > > > > > > >> > > > > > >> > > > > > > are
> > > > > > > >> > > > > > >> > > > > > > > installed, at runtime. In order
> to
> > > make
> > > > > > that
> > > > > > > >> > happen,
> > > > > > > >> > > > > I've
> > > > > > > >> > > > > > >> taken
> > > > > > > >> > > > > > >> > > the
> > > > > > > >> > > > > > >> > > > > > first
> > > > > > > >> > > > > > >> > > > > > > > step of having plugman prepare
> > > insert a
> > > > > tag
> > > > > > > into
> > > > > > > >> > > > > > >>config.xml
> > > > > > > >> > > > > > >> for
> > > > > > > >> > > > > > >> > > > each
> > > > > > > >> > > > > > >> > > > > > > > plugin. It will look like this:
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > <plugins>
> > > > > > > >> > > > > > >> > > > > > > >   <plugin
> > > id="org.apache.cordova.file"
> > > > > > > >> > > version="0.2.5"
> > > > > > > >> > > > > />
> > > > > > > >> > > > > > >> > > > > > > >   <plugin
> > > > > > > id="org.apache.cordova.file-transfer"
> > > > > > > >> > > > > > >> version="0.3.4"
> > > > > > > >> > > > > > >> > > />
> > > > > > > >> > > > > > >> > > > > > > > </plugins>
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > NB that Plugman is injecting this
> > > > > > > automatically,
> > > > > > > >> > and
> > > > > > > >> > > > > this
> > > > > > > >> > > > > > >>tag
> > > > > > > >> > > > > > >> > > > should
> > > > > > > >> > > > > > >> > > > > > NOT
> > > > > > > >> > > > > > >> > > > > > > > appear in the plugin.xml's
> > > > <config-file>
> > > > > > > tags.
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > Now I'll be adding logic to the
> > > > > config.xml
> > > > > > > >> parser
> > > > > > > >> > on
> > > > > > > >> > > > > > >>Android
> > > > > > > >> > > > > > >> > and
> > > > > > > >> > > > > > >> > > > iOS,
> > > > > > > >> > > > > > >> > > > > > but
> > > > > > > >> > > > > > >> > > > > > > > other platform maintainers will
> > have
> > > to
> > > > > > step
> > > > > > > in
> > > > > > > >> > for
> > > > > > > >> > > > the
> > > > > > > >> > > > > > >>other
> > > > > > > >> > > > > > >> > > > > > platforms.
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > Tracking the progress here:
> > > > > > > >> > > > > > >> > > > > > >
> > > > > > https://issues.apache.org/jira/browse/CB-5379
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > (If you're wondering why we have
> > > > > motivation
> > > > > > > for
> > > > > > > >> > > this,
> > > > > > > >> > > > > > >>it's to
> > > > > > > >> > > > > > >> > > make
> > > > > > > >> > > > > > >> > > > > the
> > > > > > > >> > > > > > >> > > > > > > > AppHarness more informative, and
> > more
> > > > > > > robust, by
> > > > > > > >> > > > warning
> > > > > > > >> > > > > > >>the
> > > > > > > >> > > > > > >> > user
> > > > > > > >> > > > > > >> > > > > when
> > > > > > > >> > > > > > >> > > > > > an
> > > > > > > >> > > > > > >> > > > > > > > app they've installed is looking
> > for
> > > > > > plugins
> > > > > > > the
> > > > > > > >> > > > harness
> > > > > > > >> > > > > > >> can't
> > > > > > > >> > > > > > >> > > > > provide,
> > > > > > > >> > > > > > >> > > > > > > or
> > > > > > > >> > > > > > >> > > > > > > > where versions mismatch.)
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > > > Braden
> > > > > > > >> > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >> > > > > > >
> > > > > > > >> > > > > > >> > > > > >
> > > > > > > >> > > > > > >> > > > >
> > > > > > > >> > > > > > >> > > >
> > > > > > > >> > > > > > >> > >
> > > > > > > >> > > > > > >> >
> > > > > > > >> > > > > > >>
> > > > > > > >> > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message