Return-Path: 
 <dev-return-28025-apmail-cordova-dev-archive=cordova.apache.org@cordova.apache.org>
X-Original-To: apmail-cordova-dev-archive@www.apache.org
Delivered-To: apmail-cordova-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id C7EA3104F9
	for <apmail-cordova-dev-archive@www.apache.org>;
 Thu, 14 Nov 2013 18:41:11 +0000 (UTC)
Received: (qmail 92347 invoked by uid 500); 14 Nov 2013 18:41:11 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 92327 invoked by uid 500); 14 Nov 2013 18:41:11 -0000
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cordova.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cordova.apache.org>
List-Post: <mailto:dev@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
Received: (qmail 92319 invoked by uid 99); 14 Nov 2013 18:41:11 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Nov 2013 18:41:11 +0000
X-ASF-Spam-Status: No, hits=2.5 required=5.0
	tests=FRT_ADOBE2,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.223.182 as permitted sender)
Received: from [209.85.223.182] (HELO mail-ie0-f182.google.com)
 (209.85.223.182)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Nov 2013 18:41:02 +0000
Received: by mail-ie0-f182.google.com with SMTP id e14so3265430iej.41
        for <dev@cordova.apache.org>; Thu, 14 Nov 2013 10:40:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date:message-id:subject
         :from:to:content-type;
        bh=MRgNsALfZ2RQMtiuOT/CwYCdjCpiiFJQnkjAAapuLlA=;
        b=QpSzKNtXBhF2HjFDXXsCfzVDa3WPGFHhP2AGnSJMJzB3ABEKadFGoQvZAJQ4ite5oD
         rVWw4Wg0478g62w+Brv1SoZWHY0Q7M649LVVaOWE3Dwva1tAw1YYAVDbDpeRzdqJS4yr
         bC57LmOkoMk6+X0fg9wL8SVYQ2+bK6srJCeba8GOGlEC/HQdnHm2Ji8hpMhGcCvMOjh1
         SfCHmBzaniJLUsUctkO7fmuQFmbFR+WlMWA3S0A3l++mlH1oaeISjJWRKU/rEvuN8tLP
         aArgLMxW5ZB/FsGz0nNKPU9EDHn3sqqunhM9hs8flhWbP4n8SeeI3Xzte72v/sagQw3I
         ivvw==
MIME-Version: 1.0
X-Received: by 10.50.107.70 with SMTP id ha6mr2282765igb.60.1384454441524;
 Thu, 14 Nov 2013 10:40:41 -0800 (PST)
Sender: brian.leroux@gmail.com
Received: by 10.50.114.132 with HTTP; Thu, 14 Nov 2013 10:40:41 -0800 (PST)
In-Reply-To: 
 <CAMk5LLkswhqeTmyP1_HKgvZ1SG8TmJRGVZqr46GYiYFo8aUSQw@mail.gmail.com>
References: 
 <CADVgkyOnwt_SC7zcB2WhuU6nHcTaHAdUW1G1MrSPUmDs_ty55g@mail.gmail.com>
	<CEA93F7B.1318E%shaz@adobe.com>
	<CADVgkyOOAH=YrxoqcVrWAWA0eOJwpkfX2TrknspEbnOtLriPpw@mail.gmail.com>
	<CAE6O_-ZJxRP_zDyg=aMXcWw2zhkV6p9d0TnGtQE4BowLzMFv+g@mail.gmail.com>
	<CAKP6k2uEGkxGgwHRt3P5t=HGAKF8M1572-N-=afXADdLOaa5vQ@mail.gmail.com>
	<CAE6O_-bm6X45vAV2omtFZV1wvZwgAh7d1yD_rvyRHCPH1enrkA@mail.gmail.com>
	<CAMk5LLmF5Q4nRjHo=EE0XEP3+kAG-ApeU2Krq89sTWG+_kYJ5g@mail.gmail.com>
	<CADVgkyNvBsQQVpy+Xw6xnvocYewsnLEAFfcYYE=g=0N3D8+n+g@mail.gmail.com>
	<CAOBL_k6Vbpry=sXco65vNAs925i-UU0Dj2j6-2eqU5xaU6K_Ww@mail.gmail.com>
	<CAM2q_UxQfH1N5E2uubyGqauJhOOL9=tG4LP6HkSU0yLgGxY1Aw@mail.gmail.com>
	<CAMk5LLkswhqeTmyP1_HKgvZ1SG8TmJRGVZqr46GYiYFo8aUSQw@mail.gmail.com>
Date: Thu, 14 Nov 2013 10:40:41 -0800
X-Google-Sender-Auth: Rvtxt6YFbz5pEsVksn_iY1bMLGQ
Message-ID: 
 <CADVgkyMa=Nw-6x8fFwHNMoWsmZ9Ay_Abb+MHusVCv2GGC3UkFQ@mail.gmail.com>
Subject: Re: <plugins> tag, and accessing the plugin list
From: Brian LeRoux <b@brian.io>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b10cb3331e85804eb276b20
X-Virus-Checked: Checked by ClamAV on apache.org

--047d7b10cb3331e85804eb276b20
Content-Type: text/plain; charset=ISO-8859-1

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
> > > >> > > > > > >> > > > > > > >
> > > >> > > > > > >> > > > > > >
> > > >> > > > > > >> > > > > >
> > > >> > > > > > >> > > > >
> > > >> > > > > > >> > > >
> > > >> > > > > > >> > >
> > > >> > > > > > >> >
> > > >> > > > > > >>
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

--047d7b10cb3331e85804eb276b20--