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 19:29:06 GMT
Alright. How about 4:30 PM EST UTC-5 ? Whomever is interested can join
up to the 10 participants limit.

On Thu, Nov 14, 2013 at 11:25 AM, Braden Shepherdson
<braden@chromium.org> wrote:
> I'm definitely willing to jump on a Hangout this afternoon. Anytime from
> now through about three hours from now works for me.
>
> Braden
>
>
> On Thu, Nov 14, 2013 at 2:19 PM, Anis KADRI <anis.kadri@gmail.com> wrote:
>
>> Let's google hangout about this and report back to the list yeah ?
>>
>> My main concern is user confusion like here [1]. When a plugin fails
>> to load/work, people start looking around config files and wonder why
>> it's broken and I feel like the more config stuff we add the more
>> confusion it creates.
>>
>> [1] https://github.com/imhotep/MapKit/issues/18#issuecomment-25952856
>>
>> On Thu, Nov 14, 2013 at 10:53 AM, Braden Shepherdson
>> <braden@chromium.org> wrote:
>> > I apologize for getting somewhat short in my previous email.
>> >
>> > Let me explain my comment on needing "more, and more hacky, code".
>> Because
>> > of how Plugman parses the <config-file> tags and makes the edits to the
>> XML
>> > files, it would require special-case logic to find <feature> tags and
>> > inject this extra information into them. Only some <config-file> tags are
>> > pointing at the right file and XPath, and this would have Plugman
>> examining
>> > the children of <config-file> tags instead of treating it as a black box
>> > and copying it in. My proposal of injecting new tags doesn't require
>> > anything like that, Plugman just adds an extra config-munge entry for
>> each
>> > plugin, after it's finished parsing the <config-file> tags. The patch to
>> > implement this only added a few lines.
>> >
>> > This information is being injected by Plugman into the platform
>> config.xml
>> > (the build artifact) at plugman-prepare time. It isn't visible directly
>> to
>> > plugin devs, app devs, or users. But it allows an app or plugin dev who
>> > wants to know what plugins are installed to find out. This allows
>> checking
>> > for an optional dependency, and lets AppHarness check compatibility of
>> its
>> > own plugins with those required by a child app.
>> >
>> > Braden
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Nov 14, 2013 at 1:44 PM, 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
View raw message