Return-Path: 
 <dev-return-16842-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 CA5ABD804
	for <apmail-cordova-dev-archive@www.apache.org>;
 Thu,  8 Nov 2012 19:10:18 +0000 (UTC)
Received: (qmail 71416 invoked by uid 500); 8 Nov 2012 19:10:18 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 71377 invoked by uid 500); 8 Nov 2012 19:10:18 -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 71369 invoked by uid 99); 8 Nov 2012 19:10:18 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2012 19:10:18 +0000
X-ASF-Spam-Status: No, hits=-1.3 required=5.0
	tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates
 64.18.1.183 as permitted sender)
Received: from [64.18.1.183] (HELO exprod6og102.obsmtp.com) (64.18.1.183)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2012 19:10:11 +0000
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by
 exprod6ob102.postini.com ([64.18.5.12]) with SMTP
	ID DSNKUJwDfaiB3gb1shXUkMtO1Go2PZ8k2UWz@postini.com;
 Thu, 08 Nov 2012 11:09:50 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237])
	by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
 qA8J9mHP027174
	for <dev@cordova.apache.org>; Thu, 8 Nov 2012 11:09:48 -0800 (PST)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98])
	by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qA8J9iXN018483
	for <dev@cordova.apache.org>; Thu, 8 Nov 2012 11:09:47 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by
 nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Thu, 8 Nov 2012 11:09:47
 -0800
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Thu, 8 Nov 2012 11:09:44 -0800
Subject: Re: [iOS] Cordova.plist to config.xml - deprecation
Thread-Topic: [iOS] Cordova.plist to config.xml - deprecation
Thread-Index: Ac295J4Q6+48i0KMTT+lXU2Qv92DnA==
Message-ID: <CCC1434B.10FBC%fil@adobe.com>
In-Reply-To: <3789749237392746441@unknownmsgid>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.4.120824
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Checked: Checked by ClamAV on apache.org

At least for the plugin mappings, as long as the service name as consumed
by JS is identical across all platform implementations, the plugin class
name can and needs to be platform specific.

On 11/8/12 10:35 AM, "Jesse MacFadyen" <purplecabbage@gmail.com> wrote:

>Pluginstall will always have to special case iOS(all of them really),
>because it must modify the project(s)
>
>Also, are we planning on replacing feature names in a cross device way?
>How
>do we resolve this:?
>iOS:
><key>Notification</key> <string>CDVNotification</string>
>Android:
><plugin name=3D"Notification" value=3D"org.apache.cordova.Notification"/>
>
>Also there are various other differences that are not cross platform, like
>useBrowserHistory or
>
>AllowInlineMediaPlayback.
>What is the plan for these items?
>
>Cheers,
>  Jesse
>
>Sent from my iPhone5
>
>On 2012-11-08, at 10:08 AM, Shazron <shazron@gmail.com> wrote:
>
>Hi Becky - yes Cordova.plist will go away entirely and it is to be
>replaced
>by config.xml that follows the w3c widget spec, and the format would be
>common among all the platforms (all the major ones currently). A dev can
>certainly update the .xml from Xcode but it will be plain text editing
>instead of the nice .plist editor - that is the trade-off. Having a common
>config.xml would allow a common tool across the platforms to modify this
>format -- right now I believe the tool we have (pluginstall?) would need
>to
>special case the iOS platform to read and write the .plist format.
>
>The iOS specific settings would be replaced by feature elements:
>http://www.w3.org/TR/widgets/#the-feature-element-and-its-attributes
>
>
>On Thu, Nov 8, 2012 at 6:42 AM, Becky Gibson <gibson.becky@gmail.com>
>wrote:
>
>Ok, I'm a bit confused.  Are we suggesting to get rid of the cordova.plist
>
>entirely?  Does that mean that if a dev wants to change one of those
>
>settings they have to leave Xcode and modify config.xml and update the
>
>project?   That certainly doesn't seems a bit cumbersome and not taking
>
>advantage of the OS specific tools.   I can see using config.xml for
>
>Cordova specific things like the whitelist and plug definitions but some
>of
>
>the Cordova.plist items are iOS specific.  Am I missing something?
>
>
>-becky
>
>
>
>On Thu, Nov 8, 2012 at 7:23 AM, Brian LeRoux <b@brian.io> wrote:
>
>
>any reason why we should not follow our deprec policy here?
>
>
>
>On Wed, Nov 7, 2012 at 12:20 PM, Filip Maj <fil@adobe.com> wrote:
>
>
>Yeah and it pissed off users, esp since the docs weren't updated :)
>
>
>On 11/7/12 12:00 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>
>
>Didn't Android just switch from plugins.xml + cordova.xml ->
>
>config.xml
>
>without deprecating anything ?
>
>
>
>On Wed, Nov 7, 2012 at 11:53 AM, Filip Maj <fil@adobe.com> wrote:
>
>
>IMO we should support both for at least a point revision or two and
>
>deprecate appropriately..
>
>
>On 11/7/12 11:49 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>
>
>Because generation McDonald's wants everything yesterday! Users
>
>don't
>
>like
>
>to think too much [1]
>
>
>[1]
>
>http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758
>
>
>
>On Wed, Nov 7, 2012 at 11:44 AM, Jesse <purplecabbage@gmail.com>
>
>wrote:
>
>
>I would go cold turkey.
>
>Not sure why you need to write a cli tool, just instruct users
>
>that
>
>in
>
>version 2.3 and beyond, they must use config.xml, and tell them
>
>if
>
>they are migrating, they will have to put their data in the new
>
>format.
>
>
>Not sure why we keep insisting on doing everything for everyone.
>
>but
>
>meh, I'm grumpy and old ...
>
>
>On Wed, Nov 7, 2012 at 11:25 AM, Shazron <shazron@gmail.com>
>
>wrote:
>
>Do we want to still support the .plist (thus deprecate) or go
>
>cold
>
>turkey
>
>and support config.xml only?
>
>
>I'd rather go cold turkey and write a cli tool to convert a
>
>Cordova.plist
>
>-> config.xml, which shouldn't be hard.
>
>
>
>
>--
>
>@purplecabbage
>
>risingj.com