Return-Path: 
 <dev-return-27973-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 BA1F310E67
	for <apmail-cordova-dev-archive@www.apache.org>;
 Wed, 13 Nov 2013 21:25:31 +0000 (UTC)
Received: (qmail 23006 invoked by uid 500); 13 Nov 2013 21:25:31 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 22965 invoked by uid 500); 13 Nov 2013 21:25:31 -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 22957 invoked by uid 99); 13 Nov 2013 21:25:31 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Nov 2013 21:25:31 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of gorkem.ercan@gmail.com
 designates 74.125.83.48 as permitted sender)
Received: from [74.125.83.48] (HELO mail-ee0-f48.google.com) (74.125.83.48)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Nov 2013 21:25:27 +0000
Received: by mail-ee0-f48.google.com with SMTP id e49so488306eek.35
        for <dev@cordova.apache.org>; Wed, 13 Nov 2013 13:25:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=Wyx511kfbFLvg1AJjRsdRGAY+Jv++m2Qgh6sqFLMEps=;
        b=fJn7GVvMxykyUX/S3sgjqk/h0SQKd+U9yQQgNxawunb93z1VHPMPJ2c59goqKB69Y+
         OmtldBQ1SnoDzyXzGCtHIFd1KnFpdNXjTsBtTShxRK22W9TE/MjdkXeXTdOdGfl0xAH1
         psF2qoJgTiCXJlyAK+IfkJD9uQtMlqE+XJL0/VAwOlGQpGhIL4lvehHXEl0xINsDBZjo
         oaixgi5X7gvvXUIoKONym4ZxbyhNp9Wv5Bplej/tBgAMajF0d56vK2wEQXsWzFcVza32
         oYo9GyxrICcCzypq/fA/B3L5kmVOVauxvNRmuuo1/cVM9s/X/hK+l4TFeV7L93IwQF+y
         WMOg==
MIME-Version: 1.0
X-Received: by 10.14.214.73 with SMTP id b49mr1125833eep.89.1384377905987;
 Wed, 13 Nov 2013 13:25:05 -0800 (PST)
Received: by 10.14.90.140 with HTTP; Wed, 13 Nov 2013 13:25:05 -0800 (PST)
In-Reply-To: 
 <CAMk5LLkMvkL8BhKJr8S6Xw-aQBCfU9vAUuwFV0oJAAbELGF2UA@mail.gmail.com>
References: 
 <CAMk5LL=3dW7J+Z6PnhEqq_54V=DjjYeaQrcxpLhvxfoPS7e8Lg@mail.gmail.com>
	<CA+X37cngy_7HHct9JYOpAJb32=mkiMHit3U0qLHUvMWu1a8AJw@mail.gmail.com>
	<CAKP6k2tiA6ZkBT=+T-Ln0N4Q5oZ_LRenn0ByqkDNAqnQzCdDkg@mail.gmail.com>
	<CAMk5LLkMvkL8BhKJr8S6Xw-aQBCfU9vAUuwFV0oJAAbELGF2UA@mail.gmail.com>
Date: Wed, 13 Nov 2013 16:25:05 -0500
Message-ID: 
 <CA+X37cnoSSmpSg8uruSoXL+Lk1twY4zPm3jxOqSPn1kr1P3KXw@mail.gmail.com>
Subject: Re: <plugins> tag, and accessing the plugin list
From: Gorkem Ercan <gorkem.ercan@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b62214052476a04eb1599bb
X-Virus-Checked: Checked by ClamAV on apache.org

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

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

--047d7b62214052476a04eb1599bb--