Re: PhoneGap day

[Ken Wallis]

I'll be there.

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Piotr Zalewa
Sent: Saturday, October 18, 2014 10:18 AM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Cc: Don Coleman
Subject: Re: PhoneGap day


I'll be there a well

Dnia Sat Oct 18 04:31:22 2014 Don Coleman pisze:
> I'll be there
>
>
>
>> On Oct 17, 2014, at 9:29 PM, tommy-carlos williams  
>> wrote:
>>
>> I will certainly be there.
>>
>>
>>
>>
>> On 18 October 2014 at 12:08:49, Jesse (purplecabb...@gmail.com) wrote:
>>
>> Who all is coming?
>>
>> I will be there for my first ever phonegap day. I've only been working with
>> phonegap since 2008 ...
>>
>> Cheers,
>> Jesse
>>
>>
>> @purplecabbage
>> risingj.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

--
Piotr Zalewa
Mozilla

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Re: Attending WWDC 2014?

[Ken Wallis]

I am at the Tizen dev conf tomorrow and Wednesday, would be interested in
a cordova meet as well!
-- 
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
925-931-6024





-Original Message-
From: Brian LeRoux 
Reply-To: "dev@cordova.apache.org" 
Date: Monday, June 2, 2014 at 9:09 AM
To: "dev@cordova.apache.org" 
Subject: Re: Attending WWDC 2014?

>Cordova dinner this week works for me!
>On May 30, 2014 12:49 PM, "Carlos Santana"  wrote:
>
>> I will be attending wwdc next week, I was wondering if any one else is
>>also
>> attending and want to setup a meetup.
>>
>> --
>> Carlos Santana
>> 
>>

Re: Introductory Cordova talk - next week in SF HTML5DevConf

[Ken Wallis]

I’ll be trolling the Cordova talks at htmldevconf as well. Demian Borba, one of 
our LATAM dev rel guys is also doing a mobile talk. And I’ll be at the PhoneGap 
Meetup, so looking forward to meeting some of you and catching up with others. 
;)
--
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
925-931-6024

From: Lisa Seacat DeLuca mailto:ldel...@us.ibm.com>>
Reply-To: "dev@cordova.apache.org<mailto:dev@cordova.apache.org>" 
mailto:dev@cordova.apache.org>>
Date: Tuesday, May 20, 2014 at 10:23 AM
To: "dev@cordova.apache.org<mailto:dev@cordova.apache.org>" 
mailto:dev@cordova.apache.org>>
Subject: Re: Introductory Cordova talk - next week in SF HTML5DevConf

Ross~

I pencilled you in to make sure to checkout your talk.  Mine is right before 
yours but pretty basic so I doubt you'll learn anything from mine.  :)  Are you 
going to go to the PhoneGap meetup at the Adobe offices to meet the team there 
on Wednesday (tomorrow) night?


Lisa

Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | 
ldel...@apache.org<mailto:ldel...@apache.org> | | 
ldel...@us.ibm.com<mailto:ldel...@us.ibm.com> | 
lisaseacat.com<http://www.lisaseacat.com/> | [follow @LisaSeacat on twitter] 
 | [follow Lisa Seacat DeLuca on linkedin] 
<http://www.linkedin.com/in/lisaseacat>





From:Ross Gerbasi mailto:rgerb...@gmail.com>>
To:dev mailto:dev@cordova.apache.org>>
Date:05/20/2014 11:06 AM
Subject:Re: Introductory Cordova talk - next week in SF HTML5DevConf




I will also be speaking on developing for Google Glass with HTML and
Cordova/PhoneGap. http://html5devconf.com/speakers/ross_gerbasi.html#session

-ross


On Mon, May 19, 2014 at 2:15 PM, Brian LeRoux 
mailto:b...@brian.io>> wrote:

> Axe, the invite extends to you too of course (and anyone lurking on the
> list). That evening there is a PhoneGap meetup too.
>
>
> On Mon, May 19, 2014 at 11:16 AM, Parashuram Narasimhan (MS OPEN TECH) <
> panar...@microsoft.com<mailto:panar...@microsoft.com>> wrote:
>
> > I will also be speaking at HTML5DevConf, and will be talking about using
> > http://github.com/axemclion/browser-perf for performance profiling of
> > Cordova apps.
> >
> > From: Lisa Seacat DeLuca [mailto:ldel...@us.ibm.com]
> > Sent: Monday, May 19, 2014 9:25 AM
> > To: dev@cordova.apache.org<mailto:dev@cordova.apache.org>
> > Subject: Re: Introductory Cordova talk - next week in SF HTML5DevConf
> >
> > Did I say next week... it's really this week.  the 22nd is my talk.  I
> fly
> > in on Wednesday and leave out Friday.
> >
> >
> >
> > Lisa Seacat DeLuca
> > OmniChannel Mobile Development Engineer - Apache Cordova Committer - IBM
> > Master Inventor
> > SWG Open Technologies and Cloud Performance
> > 
> >
> > Phone: 1-410-332-2128 | Mobile: 1-415-787-4589
> > E-mail: 
> > ldel...@us.ibm.com<mailto:ldel...@us.ibm.com><mailto:ldel...@us.ibm.com>
> > personal website: lisaseacat.com<http://lisaseacat.com/>
> > Chat:[Sametime:] 
> > ldel...@us.ibm.com<mailto:ldel...@us.ibm.com><mailto:ldel...@us.ibm.com>
> > Find me on: [LinkedIn: http://www.linkedin.com/in/lisaseacat] <
> > http://www.linkedin.com/in/lisaseacat>  [Twitter:
> > https://twitter.com/LisaSeacat] <https://twitter.com/LisaSeacat>  and
> > within IBM on: [IBM Connections:
> >
> https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0
> ]
> > <
> >
> https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0
> > >
> >
> > [IBM]
> >
> > 100 East Pratt St 21-2212
> > Baltimore, MD 21202-1009
> > United States
> >
> >
> >
> >
> >
> >
> > From:Brian LeRoux 
> > mailto:b...@brian.io><mailto:b...@brian.io>>
> > To:
> > "dev@cordova.apache.org<mailto:dev@cordova.apache.org><mailto:dev@cordova.apache.org>"
> >  <
> > dev@cordova.apache.org<mailto:dev@cordova.apache.org><mailto:dev@cordova.apache.org>>
> > Date:05/19/2014 11:08 AM
> > Subject:Re: Introductory Cordova talk - next week in SF
> > HTML5DevConf
> > Sent by:
> > brian.ler...@gmail.com<mailto:brian.ler...@gmail.com><mailto:brian.ler...@gmail.com>
> > 
> >
> >
> >
> > Right on, have a blast Lisa and knock em dead for us. =) I have some
> slides
> > on my github [1] the most rec

Re: Introduction

[Ken Wallis]

Welcome Staci! Glad to see another person looking at the BlackBerry
platform.
-- 
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404





-Original Message-
From: Staci Cooper 
Reply-To: "dev@cordova.apache.org" 
Date: Monday, March 17, 2014 at 11:00 AM
To: "dev@cordova.apache.org" 
Subject: Introduction

>Hello all,
>
>I've been watching the dev list for a while, and now I'd like to introduce
>myself. I've recently joined the Cordova team at IBM. As a long time user
>and supporter of open source, I'm happy to start contributing back and
>very
>excited to be working on this project.
>
>I will be working with the Windows 8, Windows Phone 8, and Blackberry
>platforms. I look forward to collaborating with and learning from this
>group!
>
>Best,
>Staci Cooper
>
>

Re: get config.xml data from js

[Ken Wallis]

‎We have had a couple of requests around this for BlackBerry. Particularly in 
the scenario where it is in combination with a custom solution/environment that 
puts custom tags into the config. In the case I remember the dev made changes 
to our app plugin [1] to expose arbitrary elements in the config.

It doesn't happen often, but for every one that we hear about, I am sure there 
are a few more that we don't.

[1] ‎http://plugins.cordova.io/#/com.blackberry.app

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Brian LeRoux
Sent: Saturday, March 1, 2014 11:20 AM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: get config.xml data from js


No, no, I'm suggesting this is a user space problem. Easily solved by the
user. (Certainly the first/only time I've heard a desire for this feature.)
On Feb 28, 2014 3:34 PM, "Jesse"  wrote:

> Yes, but then we have to agree on the format of config.json, which could
> take weeks.
>
> Something like this [1] should handle it.  Untested ...
>
>
> [1] https://gist.github.com/purplecabbage/9282132
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Feb 28, 2014 at 3:14 PM, Brian LeRoux  wrote:
>
> > So, before we go too much farther with this...what is the usecase? Could
> a
> > build step hook address the idea? (Eg write a file called config.json)
> >
> >
> > On Fri, Feb 28, 2014 at 2:57 PM, Axel Nennker 
> > wrote:
> >
> > > cordova.js is platform specific anyway.
> > >  Am 28.02.2014 23:16 schrieb "Jesse" :
> > >
> > > > So I guess things are not as standardized as we thought.
> > > >
> > > > iOS, WP7, WP8, Windows8, Ubuntu?[1] :
> > > > ../config.xml
> > > > Android :
> > > > ../../android_res/xml/config.xml
> > > > bb10 :
> > > > config.xml
> > > >
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-ubuntu/blob/cd6b3d11b58f38932797f1f4130ce40f772bdcd5/main.cpp#L66
> > > >
> > > > Still completely manageable from JavaScript; IMHO
> > > > just switch on cordova.platformId ...
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Fri, Feb 28, 2014 at 2:06 PM, Axel Nennker  >
> > > > wrote:
> > > >
> > > > > Looks better than it works.
> > > > > This does not trigger the alert. Neither with two / or three /
> after
> > > > > "file:"
> > > > > while "config.xml" alone works after I have put config.xml in www
> > > > >
> > > > > document.addEventListener(
> > > "deviceready",
> > > > > function() {
> > > > > function readConfig() {
> > > > > var xhr = new XMLHttpRequest();
> > > > > xhr.addEventListener("load", function () {
> > > > > var parser = new DOMParser();
> > > > > var doc = parser.parseFromString(xhr.responseText,
> > > > > "application/xml");
> > > > > alert("Description : " +
> > > > > doc.getElementsByTagName("description").item(0).textContent);
> > > > > });
> > > > > xhr.open("get", "file:///android_res/xml/config.xml", true);
> > > > > xhr.send();
> > > > > }
> > > > > readConfig();
> > > > >
> > > > > Anyway this is not very cross platform.
> > > > >
> > > > >
> > > > >
> > > > > 2014-02-28 22:57 GMT+01:00 Joe Bowser :
> > > > >
> > > > > > BTW: android_res and android_assets are special Android URIs that
> > > > > > access the APK directly.  They are read-only directories, and
> they
> > > > > > basically are used to access static files.  They also tend to be
> > > buggy
> > > > > > as all hell, so YMMV.
> > > > > >
> > > > > > On Fri, Feb 28, 2014 at 1:54 PM, Joe Bowser 
> > > wrote:
> > > > > > > Can't you just use an XHR to this URI:
> > > > > > > file://android_res/xml/config.xml?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Feb 28, 2014 at 1:48 PM, Jesse <
> purplecabb...@gmail.com>
> > > > > wrote:
> > > > > > >> They seem to be in the root iOS, android, and windows phone.
> > > > > > >>
> > > > > > >> NSString* path = [[NSBundle mainBundle] pathForResource:@
> > "config"
> > > > > > ofType:
> > > > > > >> @"xml"];
> > > > > > >>
> > > > > > >> int id = action.getResources().getIdentifier("config", "xml",
> > > > action.
> > > > > > >> getClass().getPackage().getName());
> > > > > > >>
> > > > > > >> *StreamResourceInfo streamInfo =
> > Application.GetResourceStream(new
> > > > > > >> Uri("config.xml", UriKind.Relative));*
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> @purplecabbage
> > > > > > >> risingj.com
> > > > > > >>
> > > > > > >>
> > > > > > >> On Fri, Feb 28, 2014 at 1:21 PM, Andrew Grieve <
> > > > agri...@chromium.org>
> > > > > > wrote:
> > > > > > >>
> > > > > > >>> config.xml isn't in the www/ on all platforms.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On Fri, Feb 28, 2014 at 4:15 PM, Jesse <
> > purplecabb...@gmail.com>
> > > > > > wrote:
> > > > > > >>>
> > > > > > >>> > function readConfig() {
> > > > > > >>> > var xhr = new XMLHttpRequest();
> > > > > > >>> > xhr.addEventListener("load", function () {
> > > > > > >>> >  

Re: w3c network information api shelved

[Ken Wallis]

Standards are certainly valuable, when bolstered by real world use cases
and data.

Specifically in relation to the networking API, it really is of somewhat
dubious value even if reporting everything correctly, as connectivity at
any given instant has no real bearing on connectivity status in the next
instant (the classic elevator example). It can be used for heuristics but
isn’t necessarily reliable in the mobile world.

-- 
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404





-Original Message-
From: Brian LeRoux 
Reply-To: "dev@cordova.apache.org" 
Date: Wednesday, February 19, 2014 at 2:26 PM
To: "dev@cordova.apache.org" 
Subject: Re: w3c network information api shelved

>Josh I appreciate your perspective but getting more inputs and outputs
>from
>Cordova and W3C is not a bad thing. Certainly there is a perception of how
>standards work.  would argue they haven't been working very well: big up
>front designs usually fail. Anyhow I welcome prototyping and discussion to
>make them, and us, better.
>
>
>On Wed, Feb 19, 2014 at 1:45 PM, Josh Soref  wrote:
>
>> Shazron wrote:
>>  >
>> http://lists.w3.org/Archives/Public/public-device-apis/2014Feb/0042.html
>>  >
>>  > our repo: 
>>https://github.com/apache/cordova-plugin-network-information
>>  >
>> > Good thing we never updated itŠ
>>
>> Based on the quirks in the documentation, it looks like the API is
>>mostly
>> useless.
>>
>>
>> ³you¹re on cellular (unspecified type)² on most of the platforms.
>>
>> Everyone was demanding something more specific than that, and yet none
>>of
>> the OS vendors are offering it, and in reality nothing useful can be
>>done
>> w/ it.
>>
>> Removing it is the right things.
>>
>>
>> On Wed, Feb 19, 2014 at 1:00 PM, Brian LeRoux  wrote:
>> > I've been encouraging w3c members to bring these issue to us and to
>>help
>> >us
>> > work through implementation. The relationship so far has been more
>>onus
>> >on
>> > us and that was probably not optimal for getting things done.
>>Hopefully
>> >we
>> > see them chime in.
>>
>>
>> Brian, that isn¹t how it works. To have a specification, you have to
>>have
>> real use cases, and real implementations, not toy use cases and not toy
>> implementations.
>>
>> The forum for discussing standards is W3C. It¹s an open email list. It¹s
>> more responsive than the Cordova project (where pull requests often get
>> lost for months). And all feedback is tracked and will be addressed.
>>
>> On 2/19/14, 4:05 PM, "Shazron"  wrote:
>>
>> > From that w3c thread, I came across this w3c github org:
>> > https://github.com/w3c-webmob
>> >
>> > Seems they are gathering data on what's out there (including Cordova
>> >APIs).
>>
>> Sure. If someone can come up with actual Use Cases, perhaps an API might
>> need to be created, but it¹s most likely the case that other APIs
>>already
>> exist (Video, Streaming, WebPerf) or will be created in those areas for
>> 80-90% of the real Use Cases, and in general specifications and software
>> should cover the 80-90%, not the 1%.
>>
>>

FW: best development methodology for Apache git?

[Ken Wallis]

Not sure if anyone else here still deals with the incubator mailing list
spamŠ ;)

Looks like more projects are looking for GitHub-like flows. Sounds like
Jake is part of the infra team, and looking for feedback?

Cheers.
-- 
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404





-Original Message-
From: Jake Farrell 
Reply-To: "gene...@incubator.apache.org" ,
"jfarr...@apache.org" 
Date: Monday, February 3, 2014 at 6:39 AM
To: "gene...@incubator.apache.org" 
Subject: Re: best development methodology for Apache git?

>Hey Sergio
>The Apache mirrors on Github are by request and run off from
>git.apache.org.
>Anyone wanting to have a svn or git project mirrored needs to submit an
>infra ticket and it can get setup.
>
>As for the Github workflows that are starting to be used, I am not a
>proponent of them. These workflows are not ideal as they repositories are
>not under any Asf control and infra can not help if there are any issues,
>its up to the project to take care of its own. Also with the JClouds and
>now Usergrid projects using this flow adds a lot of overhead for
>initial contributions as they have in the workflow the requirement to
>ensure an ICLA are on file for the contributor. Most committers do not
>have
>access to see the status of this. Also since these projects are not
>working
>directly against the primary repository it is up to them to ensure that
>committers are the only ones submitting code to the primary repository and
>then syncing that code at some point over to the ASF repositories in order
>to make a release.
>
>If we are not providing the right tooling for projects and they are
>seeking
>outside means then I would love to work and help make the correct tools
>available to make workflows easier and ensure security and policies are
>being met.
>
>-Jake
>
>
>
>
>
>On Mon, Feb 3, 2014 at 5:10 AM, Sergio Fernández <
>sergio.fernan...@salzburgresearch.at> wrote:
>
>> Hi,
>>
>> On 03/02/14 10:42, Bertrand Delacretaz wrote:
>>
>>> On Fri, Jan 31, 2014 at 6:47 PM, James Taylor 
>>> wrote:
>>>
>>>> The Phoenix project has recently come into incubation from it's former
>>>> life
>>>> as a Github project. I believe other projects have made this same
>>>> transition, so I'm looking to get some advice from them...
>>>>
>>>
>>> CouchDB has documented their Git workflow at
>>> http://wiki.apache.org/couchdb/ContributorWorkflow
>>>
>>
>> In Marmotta we adopted a Gitflow as workflow, you can find the
>> documentation at the web site:
>>
>> http://marmotta.apache.org/development.html#Source_code
>>
>> But we'd be really interested on extend that to github-like pull
>>requests,
>> in order to make easier to get contributions from new people. I think
>> that's what James is asking, and what jclouds has implemented somehow.
>>But
>> I miss some more details to actually know how they do it, specially
>>taking
>> into account that many repos at github are not properly synced.
>>
>> Cheers,
>>
>> --
>> Sergio Fernández
>> Senior Researcher
>> Knowledge and Media Technologies
>> Salzburg Research Forschungsgesellschaft mbH
>> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
>> T: +43 662 2288 318 | M: +43 660 2747 925
>> sergio.fernan...@salzburgresearch.at
>> http://www.salzburgresearch.at
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: Hangout?

[Ken Wallis]

Yup, Steve is just getting setup

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Wargo, John
Sent: Wednesday, January 29, 2014 9:21 AM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Hangout?


The hangout is in a few minutes, right?

John M. Wargo
Twitter: @johnwargo

Re: plugins.cordova.io: UX redesign

[Ken Wallis]

Looks awesome, great work and sorely needed!

I assume the filter is an ³and² operation?


-- 
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404





-Original Message-
From: Steven Gill 
Reply-To: "dev@cordova.apache.org" 
Date: Thursday, December 12, 2013 at 11:46 AM
To: "dev@cordova.apache.org" 
Subject: Re: plugins.cordova.io: UX redesign

>Awesome Job Joni!  Love it!
>
>Carlos, I think the plan for 3 is to display the readme npm style. Good
>suggestion ;). A template to give out would be a great idea. Maybe it gets
>generated in the plugin create command (did that ever make it in?)
>
>
>On Thu, Dec 12, 2013 at 11:36 AM, Josh Soref 
>wrote:
>
>> Jesse wrote:
>> - Search prominence is great,
>>
>>
>> but I am confused about the difference
>> between what the 'Find Plugins' link at the top does, and the search
>>box.
>>
>> I was confused too (+1)
>>
>> - Contribute, and Utilize seem to be given too much prominence here, and
>>
>> +1
>>
>> I'm not crazy about the word 'Utilize'.
>>
>> +1
>>
>>   Maybe 'Get Started' with subs of 'Publish a plugin' and 'Install a
>> plugin' ... ?
>>
>> - Plugin listing by ID seems overly geeky, can't we use the Name field?
>>
>> +1
>>
>> can we include latest published date,
>>
>> +1
>>
>> - It would be awesome if we could add some sort of image/logo to the
>> publish process,
>>
>> +1
>> -
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>>non-public
>> information. Any use of this information by anyone other than the
>>intended
>> recipient is prohibited. If you have received this transmission in
>>error,
>> please immediately reply to the sender and delete this information from
>> your system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be
>>unlawful.
>>
>>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Introductory Email

[Ken Wallis]

I approve of this message. ;)

-- 
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404





-Original Message-
From: Josh Soref 
Reply-To: "dev@cordova.apache.org" 
Date: Monday, December 2, 2013 at 8:11 AM
To: Cordova Dev 
Subject: Introductory Email

>Hello,
>
>As people have probably noticed, I¹m one of the BlackBerry developers
>working on Cordova / cordova-blackberry as part of the WebWorks team. We
>just released our WebWorks 2.0 Beta [1] last week.
>
>Before joining BlackBerry, I worked on the Mozilla project.
>
>Additionally, I¹ve been involved with the W3C including the WebApps and
>DAP Working Groups.
>- WebApps created the Widgets-Packaging W3 Recommendation around which
>config.xml is based.
>- DAP is the group who wrote a Contacts API ­ which was never published
>as a W3 Recommendation ­ which Cordova adopted.
>
>I also have experience w/ Windows, so there will be (and in fact are)
>pull requests from me to improve the state of Cordova there as well.
>
>(Yes, I know it¹s kind of late for me to send an introductory email. But
>we figured it made more sense for me to start contributing and send
>something like this later.)
>
>[1] 
>http://devblog.blackberry.com/2013/11/blackberry-webworks-sdk-2-0-beta-rel
>eased-with-lots-of-apache-cordova-goodness/
>-
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

plugins.cordova.io

[Ken Wallis]

Hey there. Just wondering if there are any more thoughts of exposing on the web 
page what platforms a particular plugin supports? Would make discovery much 
friendlier.

Thanks!

--
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Apache Cordova 3 Programming

[Ken Wallis]

Congratulations John!

Sent from my BlackBerry 10 smartphone.
  Original Message
From: John Wargo
Sent: Wednesday, November 6, 2013 2:43 PM
To: Cordova Dev
Reply To: dev@cordova.apache.org
Subject: Apache Cordova 3 Programming


Hello Dev,

I wanted to let you know that Apache Cordova 3 Programming is now available (in 
rough cut online at Safari Books Online: 
http://my.safaribooksonline.com/9780133521832.

I hope to have the Amazon listing sorted out soon so people can pre-order on 
Amazon. Should be available in about a month (hopefully).
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: cordova release naming -- proposal

[Ken Wallis]

‎Tres Poutine?

+1 for named releases, at least for ‎marketing purposes, but with monthly 
releases version numbers will still be important to more easily track stuff, so 
we shouldn't bury version numbers.

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Brian LeRoux
Sent: Wednesday, October 23, 2013 10:43 AM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: cordova release naming -- proposal


YES! We've been talking about this for years. Al and I felt racing horse
names would be fun. Or perhaps a concatenation of spanish words and popular
Canadian things. Beuno Syrup is way cooler than 3.2.x


On Wed, Oct 23, 2013 at 7:29 AM, Lisa Seacat DeLuca wrote:

> I propose we name the cordova releases more than just 2.x or 3.x.
>  Something fun... suggestions:
>
>- Provinces in Canada  ex. Alberta
>- Hockey teams (probably some issues with trademarks)
>- ...other Canadian inspired terms ;)
>- Easy Spanish words since Cordova is also a city in Spain.  ex. hola,
>adios, bueno, amigo,
>
>
>
> *Lisa Seacat DeLuca*
> Emerging Mobile Software Engineer - IBM Master Inventor
> SWG Emerging Internet Standards
> --
>  *Phone:* 1-410-332-2128 | *Mobile:* 1-415-787-4589*
> E-mail:* *ldel...@us.ibm.com* *
> personal website: **lisaseacat.com* *
> Chat:*[image: Sametime:] ldel...@us.ibm.com *
> Find me on:* [image: LinkedIn: 
> http://www.linkedin.com/in/lisaseacat]
>  [image: Twitter: https://twitter.com/IBMlisa]
> *and within IBM on:* [image: IBM Connections:
> https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0]
>
> [image: IBM]
>
> 100 East Pratt St 21-2212
> Baltimore, MD 21202-1009
> United States
>
>
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: API changes between 2.9.x and 3.x

[Ken Wallis]

Hey‎, overheating is a feature in Canada, and some Nordic countries.

But let's fix these types of things in 3.x. ;)

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Ian Clelland
Sent: Wednesday, October 16, 2013 12:46 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: API changes between 2.9.x and 3.x


http://xkcd.com/1172/



On Wed, Oct 16, 2013 at 3:42 PM, Ken Wallis  wrote:

> Ian 's point about bugs that have become "features" is also valid. Let's
> ensure we don't start breaking expected behaviour that is now being worked
> around.
>
> Sent from my BlackBerry 10 smartphone.
>   Original Message
> From: Brian LeRoux
> Sent: Wednesday, October 16, 2013 12:37 PM
> To: dev@cordova.apache.org
> Reply To: dev@cordova.apache.org
> Subject: Re: API changes between 2.9.x and 3.x
>
> ya no api upgrades for 2.9 series
>
> (but def should strive for API upgrades now that plugins are discreet)
>
>
> On Wed, Oct 16, 2013 at 3:18 PM, Marcel Kinard  wrote:
>
> > +1
> >
> > On Oct 16, 2013, at 3:08 PM, Joe Bowser  wrote:
> >
> > > I'm thinking that we don't want to move things
> > > like API changes back, since this could complicate the release, which
> > > should just be about stability fixes.
> >
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>
>
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: API changes between 2.9.x and 3.x

[Ken Wallis]

Ian 's point about bugs that have become "features" is also valid. Let's ensure 
we don't start breaking expected behaviour that is now being worked around.

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Brian LeRoux
Sent: Wednesday, October 16, 2013 12:37 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: API changes between 2.9.x and 3.x

ya no api upgrades for 2.9 series

(but def should strive for API upgrades now that plugins are discreet)


On Wed, Oct 16, 2013 at 3:18 PM, Marcel Kinard  wrote:

> +1
>
> On Oct 16, 2013, at 3:08 PM, Joe Bowser  wrote:
>
> > I'm thinking that we don't want to move things
> > like API changes back, since this could complicate the release, which
> > should just be about stability fixes.
>
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: About Cordova 3, plugins, and tools

[Ken Wallis]

Bryan, Jeff, keep me honest here, but there are a few BlackBerry 10 plugins 
that are almost (completely?) JS-only plugins.  For example, the BlackBerry 10 
web view implements the W3C file system spec which is mimicked by the Cordova 
File API. So the BlackBerry 10 Cordova API for File is really a JS shim for 3.x 
as well.

https://github.com/apache/cordova-plugin-file/tree/master/www/blackberry10
 
--

Ken Wallis
Senior Product Manager – WebWorks
BlackBerry
650-620-2404


From: Plaquette, Paul [paul.plaque...@intel.com]
Sent: Tuesday, September 17, 2013 9:43 AM
To: dev
Subject: About Cordova 3, plugins, and tools

Hi folks,

I need  help to better understand Cordova 3 plugins in order to upgrade
Cordova Port on Tizen.

Do Cordova 3 plugins have the same structure than PhoneGap Build plugins?

Most platforms supported by Cordova have native plugins (native means
native in the meaning of the host platform, java on android  (can they use
NPK?) Objective C on iOS and so on…)

I saw that communicating with the native side of a plugins is achieve
through a plugin object and a plugin result object

Tizen is mostly JavaScript.

Now the SDK is delivered it appear that we might implement native plug in
in C++ through two mechanism: NPRuntime, and MessagePort.

NPRuntime is NPAPI.

MessagePort is establishing a communication channel in between a web
application, our plugin, and a native C++ background only application
without a user interface. (I think is it a socket based mechanism, I have
to check to insure of this)

For that last mechanism we might have to rely on having such plugin and
plugin result objects, as it is highly asynchronous.

In order to support Cordova 3 on Tizen we need to support CLI and Plugman.

Where could I find something to help me in that task?

For example what are the part to update that relates to a specific
platforms?

Then we have to provide Cordova APIs plugins implementation on Tizen.

These APIs are implemented until Cordova 2.9.x as JavaScript shim layers
above the Tizen Web Runtime APIs.

My first attempt upgrading this to Cordova 3 architecture would be to keep
this JavaScript implementation: plugins as JavaScript plugins, shim layers
on the Tizen Web Runtime API.

Is there a kind of Cordova 3 plugin JavaScript framework that provides
support?

In doing this I wonder if I really need to provide a plugin and plugin
result object?

Then, if I do not need to provide such object I wonder where the shim layer
is going to take place in the www part of the plug in or in the src part of
the plugin  (I know we can use the config.xml file to set this)


Cordially,

Paul
~~~

Paul Plaquette,
Senior Software Engineer
Intel Corporation SAS *
*
*SSG/OTC: Open Source Technology Center*
France, Montpellier
-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: When to do "Official Apache Releases"

[Ken Wallis]

+1 to Marcel's thoughts. His situation is definitely not unique. ;)

At minimum I think it would be useful to try and solicit feedback on this from 
a wider audience than the dev list. I imagine there are more than just the 
watchers on this DL that might be bundling official packages in downstream 
distributions.
--

Ken Wallis
Senior Product Manager – WebWorks
BlackBerry
650-620-2404


From: Marcel Kinard [cmarc...@gmail.com]
Sent: Tuesday, September 10, 2013 9:20 AM
To: dev@cordova.apache.org
Subject: Re: When to do "Official Apache Releases"

+1 to still do these for each cadence release.

I'm in a somewhat unique situation where Cordova gets bundled as a downstream 
distribution into a vendor product. The vendor product uses the Cordova native 
platforms and core plugins that get embedded in the product, the product 
doesn't fetch any code from git or npm. And the product itself doesn't get 
installed in an npm-like way.  There isn't dynamic updates or dependency 
fetching. As we bundle those downstream distributions, I'm very used to using 
the official apache release tarballs.

I'm fine with it being just the native platforms and docs. We don't embed the 
Cordova docs in the product, we just link out to cordova.apache.org/docs.

And it would feel weird for an Apache project to not publish source releases.

I nobody else wants to invest the time to publish an official apache release to 
dist.apache.org, then I can own that.

-- Marcel

On Sep 3, 2013, at 12:36 PM, Andrew Grieve  wrote:

> It's been mentioned before, but with CLI, there's not a lot of utility in
> doing official apache releases (uploading signed zips to dist.apache.org).
>
> I don't think we should stop doing these entirely, but should we still do
> these for each Cadence Release? An alternative would be to do them only
> once / twice a year.
>
> Any thoughts on why / why not?
>
> Andrew


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Moving on

[Ken Wallis]

Sorry to see you go Fil, but really glad that you will still be involved. Best 
of luck with the new company!

--

Ken Wallis
Senior Product Manager – WebWorks
BlackBerry
650-620-2404


From: m...@google.com [m...@google.com] on behalf of Max Woghiren 
[m...@chromium.org]
Sent: Friday, August 30, 2013 2:50 PM
To: dev
Subject: Re: Moving on

Best of luck, Fil!


On Fri, Aug 30, 2013 at 2:48 PM, Gord Tanner  wrote:

> Best of luck dude!
>
>
> On Fri, Aug 30, 2013 at 2:45 PM, Filip Maj  wrote:
>
> > Sweet, glad there are volunteers willing to take on stuff right away!
> >
> > And yes: I've got my phonegapday EU ticket and will be booking travel
> this
> > weekend. Hopefully I'll see most of you there!
> >
> > P.S. who's going to lxjs? I'm going to be there along with a few good
> folk
> > from the Adobe Cordova team :)
> >
> >
> > On Fri, Aug 30, 2013 at 11:42 AM, Ian Clelland 
> > wrote:
> >
> > > Best of luck, Fil!
> > >
> > > Glad to hear you're not stepping away from the project entirely, but
> your
> > > CLI and Plugman efforts will be missed, for sure.
> > >
> > > Will we still see you at PGDay?
> > >
> > >
> > >
> > >
> > > On Fri, Aug 30, 2013 at 2:33 PM, Lucas Holmquist  > > >wrote:
> > >
> > > > good luck dude
> > > > On Aug 30, 2013, at 2:31 PM, Filip Maj  wrote:
> > > >
> > > > > Hey everyone,
> > > > >
> > > > > Wanted to let the community know that I'm moving on from Adobe.
> > Tuesday
> > > > > I'll be starting at Saucelabs, working on mobile automation on the
> > R&D
> > > > team.
> > > > >
> > > > > My focus is going to shift away from cordova a little bit, but not
> > > > > entirely. My plan is to be involved a lot more in cordova-medic
> > moving
> > > > > forward, but stepping away from the tooling (plugman + cli), JS,
> spec
> > > and
> > > > > platform work.
> > > > >
> > > > > As such, I'll be removing myself as "lead" in JIRA on the
> cordovaJS,
> > > > > mobile-spec, cli and plugman components. If any committers want to
> > step
> > > > up
> > > > > and take on a more involved role on those components, I'd recommend
> > > > > assigning yourself as lead in JIRA to those, that's always an easy
> > way
> > > to
> > > > > be intimately familiar with issues coming down the pipeline :)
> > > > >
> > > > > Looking forward to working more on medic with you all!
> > > > >
> > > > > Cheers,
> > > > > Fil
> > > >
> > > >
> > >
> >
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Post 3.0 release committer and community meeting

[Ken Wallis]

‎I won't be able to attend at the Toronto office, but I will watch, and perhaps 
try to push comments through the BlackBerry guys. ;)

Sent from my BlackBerry 10 smartphone on the Bell network.
From: Michal Mocny
Sent: Wednesday, August 14, 2013 12:46 PM
To: dev
Reply To: dev@cordova.apache.org
Subject: Re: Post 3.0 release committer and community meeting


Not in the list Andrew sent out, but there were a lot of volunteers in
previous emails, whom I think would be served fine with the viewing only
option.  I think limiting the amount of speakers to those that actually
have something to say will keep things from getting out of hand.

I don't mean this to deter anyone who does have something to say from
asking for an invite, I'm just reminding that everyone will be able to
watch even past the 10-limit.


On Wed, Aug 14, 2013 at 12:31 PM, Filip Maj  wrote:

> Did we hit the 10 co-lo max for hangouts?
>
> On 8/14/13 9:28 AM, "Michal Mocny"  wrote:
>
> >Keep in mind that everyone will be able to watch this live or recorded
> >later.  You only need a direct invite if you would like to speak.
> >
> >
> >On Wed, Aug 14, 2013 at 11:58 AM, Lisa Seacat DeLuca
> >wrote:
> >
> >> Is it too late to get invited to this?  ldeluca.  I'm not colocated but
> >>I
> >> did add you to my G+ account!
> >>
> >>
> >> Lisa Seacat DeLuca
> >> ldel...@apache.org
> >>
> >> - Message from Andrew Grieve  on Wed, 14 Aug
> >> 2013 11:44:48 -0400 -
> >> To:
> >> dev 
> >> Subject:
> >> Re: Post 3.0 release committer and community meeting
> >> Reminder to let me know which person from each co-lo to invite!
> >>
> >> Right now I have a Circle with:
> >>
> >> > >> agrieve, co-location=Google Waterloo
> >> > >> aharding, co-location=Adobe Vancouver
> >> > >> jheifetz, co-location=BlackBerry Toronto
> >> > >> devgeeks, co-location=n/a Melbourne, Australia
> >> > >> aogilvie, co-location=n/a Tokyo, Japan.
> >> > >> jamesjong, co-location=IBM Raleigh
> >> > >> lucasholmquist, co-location=Red Hat, Upstate New York
> >> > >> lorinbeer, co-location=Adobe San Francisco
> >>
>
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Post 3.0 release committer and community meeting

[Ken Wallis]

Bringing the list to the top and adding myself:

agrieve, co-location=Google Waterloo
mmocny, co-location=Google Waterloo
maxw, co-location=Google Waterloo
aharding, co-location=Adobe Vancouver
filmaj, co-location=Adobe Vancouver
stevegill, co-location=Adobe San Francisco
bhiggins, co-location=BlackBerry Toronto
jheifetz, co-location=BlackBerry Toronto
devgeeks, co-location=n/a Melbourne, Australia
aogilvie, co-location=n/a Tokyo, Japan.
drkemp, co-location=Google Waterloo
iclelland, co-location=Google Waterloo
jamesjong, co-location=IBM Raleigh
kwallis, co-location=n/a near-Toronto, Canada

--

Ken Wallis

Senior Product Manager – WebWorks

BlackBerry

650-620-2404


From: Shazron [shaz...@gmail.com]
Sent: Wednesday, August 07, 2013 11:17 AM
To: dev@cordova.apache.org
Subject: Re: Post 3.0 release committer and community meeting

Ditto - will try to call in since it's at a sane 7:30 am here (audio only
most like). The show must go on


On Wed, Aug 7, 2013 at 11:02 PM, Joe Bowser  wrote:

> I can't make this meeting. I'm out of the office until the 16th.
> On Aug 7, 2013 8:06 AM, "James Jong"  wrote:
>
> > On Aug 7, 2013, at 9:19 AM, Ian Clelland  wrote:
> >
> > >>
> > >>> Attendees: If you plan to attend, could you add your name to this
> list
> > >>> (inline so that the list grows) and say whether you plan to be
> > >> co-located:
> > >>> agrieve, co-location=Google Waterloo
> > >>> mmocny, co-location=Google Waterloo
> > >>> maxw, co-location=Google Waterloo
> > >>> aharding, co-location=Adobe Vancouver
> > >>> filmaj, co-location=Adobe Vancouver
> > >>> stevegill, co-location=Adobe San Francisco
> > >>> bhiggins, co-location=BlackBerry Toronto
> > >>> jheifetz, co-location=BlackBerry Toronto
> > >>> devgeeks, co-location=n/a Melbourne, Australia
> > >>> aogilvie, co-location=n/a Tokyo, Japan.
> > >>> drkemp, co-location=Google Waterloo
> > >>
> > >> iclelland, co-location=Google Waterloo
> > >> jamesjong, co-location=IBM Raleigh
> > >
> > >
> > >
> > >> Agenda (feel free to add items inline):
> > >>
> > >>> - Release artifacts and process redux
> > >>> - Should platform releases still be coupled?
> > >>> - Does semver make more sense to us now that components are more
> > >> decoupled?
> > >>> - Deprecation policy improvements?
> > >>> - Can we use cordova-registry to allow older versions of things when
> > >> APIs are removed?
> > >>> - Can we have our plugin API surface versioned separately from our
> > >> component versions?
> > >>> - Shortterm plans for Medic
> > >>> - Buildbot?
> > >>> - Should mobile-spec autotests be pulled out?
> > >>> - 4.0 goals, timeline, and priorities
> > >>> - Platforms as build artifacts - Is this our goal? what's
> > >> big hurdles remain?
> > >>> - Apps & Plugins to have the same feature set (dependencies, merges/,
> > >> etc)
> > >>
> >
> >
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Posting Blog Posts

[Ken Wallis]

+1 as well. I plan to write some posts on BlackBerry and Cordova and a method 
to "link" would be great.

Sent from my BlackBerry 10 smartphone on the Bell network.
From: dguald...@gmail.com
Sent: Tuesday, August 6, 2013 1:48 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: Posting Blog Posts


+1

Sent from my BlackBerry® wireless device

-Original Message-
From: Tommy Williams 
Date: Tue, 6 Aug 2013 10:46:15
To: 
Reply-To: dev@cordova.apache.org
Subject: Re: Posting Blog Posts

+1 from me as well.

I like the idea of official posts looking official as well as the side
effect of third party posts getting the traffic benefits.

- tommy
On 7 Aug 2013 03:44, "Ian Clelland"  wrote:

> +1. That's a good approach to separating them, and should encourage
> third-party authors to submit pieces -- knowing that Apache will drive
> traffic to their site.
>
>
>
>
> On Tue, Aug 6, 2013 at 1:35 PM, David Kemp  wrote:
>
> > +1 for Michals approach
> >
> >
> > On Tue, Aug 6, 2013 at 1:27 PM, Michal Mocny 
> wrote:
> >
> > > I'de like to make a proposal about how we go about publishing certain
> > blog
> > > posts.  I think this is a good practice for Organizational-type blogs
> to
> > > clearly identify posts which are (1) genuinely origination from the
> > > organization, vs (2) those which are just being curated from within the
> > > community.  This is already widely accepted practice on many other
> blogs
> > as
> > > well as on Twitter, and I think already the strategy that PhoneGap blog
> > > uses.
> > >
> > > Basically:
> > > (1) If the content has to do with cordova-core, i.e. announcing
> releases,
> > > or publishing guides, etc., we should publish the full text directly on
> > the
> > > cordova Blog (by whichever author), as-if written by the organization.
> > > (2) If the content was written by a contributor and is worth curating
> for
> > > the whole community, but is not really core ie. non-core plugins, dev
> > tips,
> > > research, opinion-pieces, statistics, etc., post a short description,
> > > perhaps adding a document-snippet, but then link to the externally
> hosted
> > > content, making it clearly not written by the organization.
> > >
> > > I think this makes it both easier to identify those posts which are
> > really
> > > organizationally important, as well as giving us a way to post things
> > that
> > > otherwise maybe would not have made the cut.
> > >
> > > WDYT?
> > >
> > > -Michal
> > >
> > >
> > > On Tue, Aug 6, 2013 at 10:41 AM, Andrew Grieve 
> > > wrote:
> > >
> > > > Here's a draft of a "how to write a blog post". I intend to add this
> to
> > > the
> > > > website's README.md. Wanted to get some feedback / +1 since this is a
> > > > "process".
> > > >
> > > >  Writting a Blog Post
> > > > > 
> > > > > Blog posts live in `www/_posts`. To create a new post:
> > > > >   1. Copy one of the existing posts into a new file (changing the
> > name
> > > > > appropriately).
> > > > >   2. Run "rake serve" in the background.
> > > > >   3. Draft your post.
> > > > >   4. Get your post reviewed by at least one other committer
> > > > >  1. via http://reviews.apache.org.
> > > > >  2. Should be able to do this by running the "post-review"
> tool.
> > If
> > > > > the tool is not working, upload the diff manually (via "svn diff >
> > > file",
> > > > > and be sure to add the "cordova" group to the review request).
> > > > >   5. Update the file name to reflect the commit date (if necessary)
> > > > >   6. Run "rake build"
> > > > >   7. svn commit
> > > >
> > > > *Post guidelines:*
> > > > >   * Use the post title as the first header. Including a header as
> > well
> > > > > makes the snippet on the front page look really bad.
> > > > >   * Use `rake serve` and refresh frequently. Jekyll does not do a
> > good
> > > > job
> > > > > at telling you where errors are made.
> > > > >   * Review your post yourself before asking for a review. This
> > includes
> > > > > spell-check :).
> > > >
> > >
> >
>


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Ignoring SSL Errors for InAppBrowser

[Ken Wallis]

It came up this morning that Enterprise could use something like this. An app 
that is deployed into the Enterprise secure container, already being 
enforced/controlled by corporate firewall etc., and approved for use internally 
might want "blanket" access to any internal domain.
--

Ken Wallis

Senior Product Manager – WebWorks

BlackBerry

289-261-4369


From: Josh Soref [jso...@blackberry.com]
Sent: Tuesday, July 23, 2013 1:20 PM
To: dev@cordova.apache.org
Cc: ramandeep.si...@barco.com
Subject: RE: Ignoring SSL Errors for InAppBrowser

A simple flag is definitely wrong... a static whitelist could be interesting.

Are there real use cases beyond `localhost`?

If someone whitelists any site that isn't on the local device, then when I'm in 
an Internet Café, the wrong thing can happen (and in certain cases, the wrong 
thing probably will happen).

Making it easy for people to write broken applications doesn't seem to be a 
good "value-add". Unfortunately, people will do the wrong thing and not care 
about their customers

But, this is just my personal opinion

> -Original Message-
> From: Shazron [mailto:shaz...@gmail.com]
> Sent: Tuesday, July 23, 2013 3:40 PM
> To: dev@cordova.apache.org
> Cc: ramandeep.si...@barco.com
> Subject: Re: Ignoring SSL Errors for InAppBrowser
>
> Why the js callback and not just the static white-list?
> the js callback allows someone to change the security rules at runtime
> which could be a hole I suppose.
>
>
> On Tue, Jul 23, 2013 at 12:26 PM, Andrew Grieve
> wrote:
>
> > https://issues.apache.org/jira/browse/CB-3576
> >
> > There are pulls request for adding to iOS & Android that add:
> >
> > window.open(url, '_blank', 'location=yes,validatessl=no');
> >
> >
> > Given that this is security-related though, I wanted to get more eyes on
> > it. Other proposals are to have each questionable cert go through a JS
> > callback:
> >
> > var iab = window.open(...);
> > iab.onSSLError = function(url) {
> >return !!/^https://myalloweddomain.com\//.exec(url);
> > };
> >
> > Or to add a white-list to your config.xml for allowed self-signed https:
> > addresses.
> >
> > If your app is not going to validate ssl certs, then perhaps restricting
> > the scope of it isn't really increasing security anyways. It's certainly
> > useful for development to be able to turn it off, but maybe for that reason
> > we should turn it off globally with a  tag?
> >
> > Thoughts? Willingness from other platforms?
> >

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: blackberry10 build

[Ken Wallis]

Apparently I am getting older faster than I thought, seeing y's where there are 
i's...

Sent from my BlackBerry 10 smartphone.
From: Ken Wallis
Sent: Monday, July 22, 2013 1:05 PM
To: dev@cordova.apache.org; dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: blackberry10 build


Bryan is the man. Bryan H. that is. :P

Sent from my BlackBerry 10 smartphone.
From: Brian LeRoux
Sent: Monday, July 22, 2013 12:41 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: blackberry10 build


Wow, this is awesome thanks Bryan!

On Mon, Jul 22, 2013 at 3:32 PM, Bryan Higgins  wrote:
> I've entered the following issues into JIRA and we will be working to get
> them resolved over the next two weeks.
>
> Code:
>
> - [CB-4273] CLI pass through of command line args
>
> - [CB-4340] Query device to get PIN (no longer required in
> blackberry10.json)
>
> - [CB-4342] Auto-detect connected USB device
>
> - [CB-4344] Auto-detect started simulator
>
> - [CB-4345] Improve error output for common failure scenarios
>
> - [CB-4346] Change DEFAULT_BAR_NAME, remove from create script
>
> Docs:
>
> - [CB-4347] Restore improvements with screen shots / BBNDK path instructions
>
> - [CB-4349] Add debug token section
>
> - [CB-4351] Add project settings section (config.xml)
>
>
> On Mon, Jul 22, 2013 at 11:49 AM, Bryan Higgins wrote:
>
>> Matt - thanks for the detailed feedback!
>>
>> I'll be entering in JIRAs for the tasks needed to tighten up the bb10 CLI
>> experience today.
>>
>>
>> On Mon, Jul 22, 2013 at 11:20 AM, Lucas Holmquist wrote:
>>
>>> Nice write up,
>>> On Jul 22, 2013, at 11:14 AM, Matt Lantz  wrote:
>>>
>>> > Developing a BlackBerry10 App with Cordova 3.0.0
>>> > 
>>> >
>>> > So, I started by downloading all the appropriate developer SDKs from
>>> BlackBerry. Though in retrospect I suppose I only needed the webworks one.
>>> > After downloading and installing those. I followed the instructions
>>> ensuring that I had nodejs installed, and performed an installation of
>>> cordova. I performed the create app which went fine. I decided first to
>>> test run iOS given that I live in an OSX world. I added iOS, made a couple
>>> tweaks and ran it in the simulator flawlessly. Awesome experience.
>>> >
>>> > On to BlackBerry. I first attempted to add the blackberry platform. It
>>> responded with no platform. Since I knew a handful of stuff that Gord had
>>> been working on for BlackBerry builds I attempted, qnx, playbook, bb10, and
>>> then blackberry10 that seemed to be the golden key. After getting the
>>> platform set, I decided to experiment a bit.
>>> >
>>> > I ran the build, and understood how it pulled over the www folder data
>>> to the platforms. I had a couple issues with this though. It seemed that
>>> any custom writing I had done in the platform itself (blackberry10) was
>>> overwritten, including the config.xml which meant if I did an upgrade to
>>> the www directory even changed the file config.xml with new name etc it
>>> overwrites the custom stuff I set in the blackberry10 platform, with
>>> default values of 'WebWorks Application' etc.
>>> >
>>> > So I set some details such as name and author and then added some text
>>> to the index.html page of the www directory for the blackberry10 platform
>>> directory. Then I decided to test run it on a blackberry device.
>>> >
>>> > Since I had previous experience doing this, I got my debug tokens and
>>> got all that set by following the instructions on BlackBerry's website.
>>> This hit a snag in that it appeared I had used a short password.
>>> BlackBerry's website says that the csjpin must be between 6-10 alphanumeric
>>> characters. But it then turns out that WebWorks needs at least 8
>>> alphanumeric characters. That was a pain, and lots of wasted time but I got
>>> through that.
>>> >
>>> > I didn't even bother installing the blackberry emulator since my
>>> previous experience with it sucked, I decided to try it on a real device. I
>>> had all the tokens in place and attempted to do a build with the
>>> instructions on the blackberry website. That failed with no signing
>>> password provided statement. I did some digging very confusingly since I
>>> had set all those details with my signing keys etc according to the
>>> blackberry website. 

Re: blackberry10 build

[Ken Wallis]

Bryan is the man. Bryan H. that is. :P

Sent from my BlackBerry 10 smartphone.
From: Brian LeRoux
Sent: Monday, July 22, 2013 12:41 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: blackberry10 build


Wow, this is awesome thanks Bryan!

On Mon, Jul 22, 2013 at 3:32 PM, Bryan Higgins  wrote:
> I've entered the following issues into JIRA and we will be working to get
> them resolved over the next two weeks.
>
> Code:
>
> - [CB-4273] CLI pass through of command line args
>
> - [CB-4340] Query device to get PIN (no longer required in
> blackberry10.json)
>
> - [CB-4342] Auto-detect connected USB device
>
> - [CB-4344] Auto-detect started simulator
>
> - [CB-4345] Improve error output for common failure scenarios
>
> - [CB-4346] Change DEFAULT_BAR_NAME, remove from create script
>
> Docs:
>
> - [CB-4347] Restore improvements with screen shots / BBNDK path instructions
>
> - [CB-4349] Add debug token section
>
> - [CB-4351] Add project settings section (config.xml)
>
>
> On Mon, Jul 22, 2013 at 11:49 AM, Bryan Higgins wrote:
>
>> Matt - thanks for the detailed feedback!
>>
>> I'll be entering in JIRAs for the tasks needed to tighten up the bb10 CLI
>> experience today.
>>
>>
>> On Mon, Jul 22, 2013 at 11:20 AM, Lucas Holmquist wrote:
>>
>>> Nice write up,
>>> On Jul 22, 2013, at 11:14 AM, Matt Lantz  wrote:
>>>
>>> > Developing a BlackBerry10 App with Cordova 3.0.0
>>> > 
>>> >
>>> > So, I started by downloading all the appropriate developer SDKs from
>>> BlackBerry. Though in retrospect I suppose I only needed the webworks one.
>>> > After downloading and installing those. I followed the instructions
>>> ensuring that I had nodejs installed, and performed an installation of
>>> cordova. I performed the create app which went fine. I decided first to
>>> test run iOS given that I live in an OSX world. I added iOS, made a couple
>>> tweaks and ran it in the simulator flawlessly. Awesome experience.
>>> >
>>> > On to BlackBerry. I first attempted to add the blackberry platform. It
>>> responded with no platform. Since I knew a handful of stuff that Gord had
>>> been working on for BlackBerry builds I attempted, qnx, playbook, bb10, and
>>> then blackberry10 that seemed to be the golden key. After getting the
>>> platform set, I decided to experiment a bit.
>>> >
>>> > I ran the build, and understood how it pulled over the www folder data
>>> to the platforms. I had a couple issues with this though. It seemed that
>>> any custom writing I had done in the platform itself (blackberry10) was
>>> overwritten, including the config.xml which meant if I did an upgrade to
>>> the www directory even changed the file config.xml with new name etc it
>>> overwrites the custom stuff I set in the blackberry10 platform, with
>>> default values of 'WebWorks Application' etc.
>>> >
>>> > So I set some details such as name and author and then added some text
>>> to the index.html page of the www directory for the blackberry10 platform
>>> directory. Then I decided to test run it on a blackberry device.
>>> >
>>> > Since I had previous experience doing this, I got my debug tokens and
>>> got all that set by following the instructions on BlackBerry's website.
>>> This hit a snag in that it appeared I had used a short password.
>>> BlackBerry's website says that the csjpin must be between 6-10 alphanumeric
>>> characters. But it then turns out that WebWorks needs at least 8
>>> alphanumeric characters. That was a pain, and lots of wasted time but I got
>>> through that.
>>> >
>>> > I didn't even bother installing the blackberry emulator since my
>>> previous experience with it sucked, I decided to try it on a real device. I
>>> had all the tokens in place and attempted to do a build with the
>>> instructions on the blackberry website. That failed with no signing
>>> password provided statement. I did some digging very confusingly since I
>>> had set all those details with my signing keys etc according to the
>>> blackberry website. I messaged the mailing list in the end, where Fil
>>> helped me out by suggesting I run the cordova run command.
>>> >
>>> > cordova -d run blackberry10
>>> >
>>> > I had no idea there was such a command since I had been following the
>>> CLI instructions on Phonegap's website, and didn't see that anywhere. I
>>> attempted that and it failed same statement of the no signing password
>>> provided. I was all the more confused, read everything scoured
>>> stackoverflow, and finally posted again to the mailing list, and got a
>>> response from Jeffrey Heifetz talking about the
>>> %home%/.cordova/blackberry10.json.
>>> >
>>> > Just before I got Jeff's response I had decided to try upgrading my
>>> version of Cordova. According to:
>>> >
>>> > cordova -v
>>> >
>>> > I had cordova 3.0.0rc1 which was not giving me any information about
>>> the blackberry10.json file I had to modify. After performing:
>>> >
>>> > sudo npm update -g cordova
>>

Re: blackberry10 build

[Ken Wallis]

Apparently I am getting older faster than I thought, seeing y's where there are 
i's...

Sent from my BlackBerry 10 smartphone.
From: Ken Wallis
Sent: Monday, July 22, 2013 1:05 PM
To: dev@cordova.apache.org; dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: blackberry10 build


Bryan is the man. Bryan H. that is. :P

Sent from my BlackBerry 10 smartphone.
From: Brian LeRoux
Sent: Monday, July 22, 2013 12:41 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: blackberry10 build


Wow, this is awesome thanks Bryan!

On Mon, Jul 22, 2013 at 3:32 PM, Bryan Higgins  wrote:
> I've entered the following issues into JIRA and we will be working to get
> them resolved over the next two weeks.
>
> Code:
>
> - [CB-4273] CLI pass through of command line args
>
> - [CB-4340] Query device to get PIN (no longer required in
> blackberry10.json)
>
> - [CB-4342] Auto-detect connected USB device
>
> - [CB-4344] Auto-detect started simulator
>
> - [CB-4345] Improve error output for common failure scenarios
>
> - [CB-4346] Change DEFAULT_BAR_NAME, remove from create script
>
> Docs:
>
> - [CB-4347] Restore improvements with screen shots / BBNDK path instructions
>
> - [CB-4349] Add debug token section
>
> - [CB-4351] Add project settings section (config.xml)
>
>
> On Mon, Jul 22, 2013 at 11:49 AM, Bryan Higgins wrote:
>
>> Matt - thanks for the detailed feedback!
>>
>> I'll be entering in JIRAs for the tasks needed to tighten up the bb10 CLI
>> experience today.
>>
>>
>> On Mon, Jul 22, 2013 at 11:20 AM, Lucas Holmquist wrote:
>>
>>> Nice write up,
>>> On Jul 22, 2013, at 11:14 AM, Matt Lantz  wrote:
>>>
>>> > Developing a BlackBerry10 App with Cordova 3.0.0
>>> > 
>>> >
>>> > So, I started by downloading all the appropriate developer SDKs from
>>> BlackBerry. Though in retrospect I suppose I only needed the webworks one.
>>> > After downloading and installing those. I followed the instructions
>>> ensuring that I had nodejs installed, and performed an installation of
>>> cordova. I performed the create app which went fine. I decided first to
>>> test run iOS given that I live in an OSX world. I added iOS, made a couple
>>> tweaks and ran it in the simulator flawlessly. Awesome experience.
>>> >
>>> > On to BlackBerry. I first attempted to add the blackberry platform. It
>>> responded with no platform. Since I knew a handful of stuff that Gord had
>>> been working on for BlackBerry builds I attempted, qnx, playbook, bb10, and
>>> then blackberry10 that seemed to be the golden key. After getting the
>>> platform set, I decided to experiment a bit.
>>> >
>>> > I ran the build, and understood how it pulled over the www folder data
>>> to the platforms. I had a couple issues with this though. It seemed that
>>> any custom writing I had done in the platform itself (blackberry10) was
>>> overwritten, including the config.xml which meant if I did an upgrade to
>>> the www directory even changed the file config.xml with new name etc it
>>> overwrites the custom stuff I set in the blackberry10 platform, with
>>> default values of 'WebWorks Application' etc.
>>> >
>>> > So I set some details such as name and author and then added some text
>>> to the index.html page of the www directory for the blackberry10 platform
>>> directory. Then I decided to test run it on a blackberry device.
>>> >
>>> > Since I had previous experience doing this, I got my debug tokens and
>>> got all that set by following the instructions on BlackBerry's website.
>>> This hit a snag in that it appeared I had used a short password.
>>> BlackBerry's website says that the csjpin must be between 6-10 alphanumeric
>>> characters. But it then turns out that WebWorks needs at least 8
>>> alphanumeric characters. That was a pain, and lots of wasted time but I got
>>> through that.
>>> >
>>> > I didn't even bother installing the blackberry emulator since my
>>> previous experience with it sucked, I decided to try it on a real device. I
>>> had all the tokens in place and attempted to do a build with the
>>> instructions on the blackberry website. That failed with no signing
>>> password provided statement. I did some digging very confusingly since I
>>> had set all those details with my signing keys etc according to the
>>> blackberry website. 

Re: PG Day / OSCON

[Ken Wallis]

I arrive Thursday evening as well, along with a number of BlackBerry folks. 
Would love to meet up.

Sent from my BlackBerry 10 smartphone.
From: Andrew Grieve
Sent: Tuesday, July 16, 2013 10:48 PM
To: dev
Reply To: dev@cordova.apache.org
Subject: Re: PG Day / OSCON


I'll be arriving Thursday evening.


On Tue, Jul 16, 2013 at 10:39 PM, Marcel Kinard  wrote:

> I'll be in Portland for PG Day and OSCON, arriving Wed afternoon. Would be
> awesome to meet other folks. Ping me if you'd like to get together for
> beverages / meal / activity.
>
> -- Marcel Kinard

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Post 3.0 release committer and community meeting

[Ken Wallis]

Definitely a good idea.

Sent from my BlackBerry 10 smartphone.
From: Brian LeRoux
Sent: Monday, July 15, 2013 5:45 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Post 3.0 release committer and community meeting


Hey everyone, we're in the final stretch to releasing 3.0 and I think
long past due to have an open discussion w/ the committership and
larger community. I think we should let the dust settle from 3.0 for a
couple of weeks before having this meeting. I'd like to propose the
week of August 12th.

If that all sounds good, we could setup a Google Hangout, and get an
agenda started:

- release artifacts and process redux
- 4.0 goals, timeline, and priorities

Comments pls!

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Plugins and IP

[Ken Wallis]

On BB10, that native side gets compiled into a .so file that you would 
distribute.

Of course there is still the javascript side. Depends on which side of the 
plugin you are worried about IP in.
--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Simon MacDonald [simon.macdon...@gmail.com]
Sent: Tuesday, June 18, 2013 7:14 AM
To: dev@cordova.apache.org
Subject: Re: Plugins and IP

Same deal on Android except you would use a jar or if UI is involved a
library project.
Simon Mac Donald
http://hi.im/simonmacdonald


On Tue, Jun 18, 2013 at 10:07 AM, Shazron  wrote:
> Forgot to mention, you should build the lib as a fat binary with all
> architectures, don't forget i386 if your users plan to test on the Simulator
>
>
> On Tue, Jun 18, 2013 at 7:04 AM, Shazron  wrote:
>
>> For iOS plugins, compile the source as a lib (.a file). For example, in
>> the TestFlightPlugin I include TestFlight's lib:
>> https://github.com/shazron/TestFlightPlugin
>> https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml#L35
>>
>>  and provide the headers of course
>>
>>
>> On Tue, Jun 18, 2013 at 6:42 AM, Wargo, John  wrote:
>>
>>> Any recommendations on the best way to implement plugins while protecting
>>> the source code? Our development teams are trying to figure out the most
>>> efficient way to deliver Cordova plugins to our customers but hide the IP
>>> and I would like to learn how others are managing this.
>>>
>>>
>>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: We need better contributions from new people

[Ken Wallis]

It is important to ensure that code coming in is good quality, I think we can 
all appreciate that.

I don't think that is separate or instead of the ability to be agile, which we 
also see as a positive for this community. From what I have read on this 
thread, it sounds like our ability to be agile and address bugs quickly might 
be hampered by not having efficient mechanisms for getting feedback and bugs 
back from the user base?

--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: m...@google.com [m...@google.com] on behalf of Max Woghiren 
[m...@chromium.org]
Sent: Wednesday, June 12, 2013 7:35 AM
To: dev
Subject: Re: We need better contributions from new people

I agree with Ian—reviewing and testing just needs to be more thorough.


On Wed, Jun 12, 2013 at 10:17 AM, Michal Mocny  wrote:

> Before we go changing process, is this really a systemic issue?  Bugs
> happen, and people sometimes land code, I'de rather be nimble in fixing
> those issues than rigid in preventing them.  Personal opinion.
>
> -Michal
>
>
> On Wed, Jun 12, 2013 at 9:54 AM, Ian Clelland  >wrote:
>
> > That's not an issue of "we need better contributions from new people",
> > that's "We, the committers, need to be more diligent in reviewing and
> > testing before committing".
> >
> > We shouldn't be discouraging contributions from anyone, but we don't have
> > to accept every pull request as-is, either. We can push back on the patch
> > if it isn't clean enough, or if it isn't clear that it's the right
> > solution, or even if it doesn't come with tests / docs.
> >
> > I'd have no problem with a lot more pull requests, if there was healthy
> > discussion on JIRA for each one, including the core committers and the
> > original reporter, before accepting (or rejecting) them.
> >
> > Regarding this particular commit, the original patch is ugly, and
> probably
> > shouldn't have been accepted without some cleanup, review, and attached
> > tests. The additional issue that it caused, though, is obviously
> something
> > that wasn't covered by our existing tests. It was only noticed a couple
> of
> > months later, in a post on StackOverflow, and as far as I can tell, it
> was
> > only mentioned in Github 18 days ago, and Andrew was right on it. (He's
> not
> > working on it currently, for other reasons)
> >
> > That regression doesn't seem to me to be a failure in process, so much
> as a
> > gap in our test framework (which we can rectify easily enough) and maybe
> an
> > issue of not-paying-enough-attention-to-stackoverflow, or
> > not-having-a-clear-channel-to-report-bugs. Maybe if it were easier for
> > people to tell us when something broke and we didn't catch it, we might
> > have fixed this a month sooner.
> >
> >
> >
> > On Wed, Jun 12, 2013 at 2:09 AM, Joe Bowser  wrote:
> >
> > > Hey
> > >
> > > I decided to check my e-mail and respond to an issue.  It turns out
> > > that we're not properly testing or even checking the pull requests
> > > that we're getting into the project. The bug in question is CB-3766,
> > > which was caused by a patch accepted to fix CB-2458.  The error isn't
> > > totally obvious, and doesn't get easily picked up on unit test (our
> > > CordovaWebView test mostly works, but fires a TIMING ERROR), but if
> > > you use an emulator, due to the emulator's crappiness, it apparently
> > > creates an ugly stack trace.
> > >
> > > Honestly, there's no way that this should have made it in.  I
> > > personally think that I'm going to have to rename loadUrlIntoView to
> > > initAndLoadUrl or something more obvious, since it's too similar to
> > > loadUrl.  That being said, we need to be more strict about quality
> > > while at the same time encouraging people to contribute.  I'd rather
> > > deal with hundreds of pull requests than hundreds of issues where
> > > people know the answer but don't tell you.
> > >
> > > Any ideas how we can accomplish this?  Has anyone else seen pull
> > > requests get in that shouldn't have?
> > >
> > > Joe
> > >
> >
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Fixing Issue

[Ken Wallis]

Hi Lolitha, I am not sure exactly what issue you are having?

Thanks.

--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Lolitha Ratnayake [lolith...@gmail.com]
Sent: Tuesday, June 11, 2013 2:16 AM
To: dev@cordova.apache.org
Subject: Fixing Issue

Hi everyone,
I have done some research on two way SSL (mutual SSL) in blackberry native
java. (BB OS 7 and earlier) I saw this issue on JIRA
https://issues.apache.org/jira/browse/CB-3351
I would like to try this out. In native it's not much. Just
HTTPSConection.open(url);
Before that client and CA certificate must be installed in the device via
Desktop studio or through email.
As I'm noob to this cordova/apache contribution, could anyone please tell
me what to do next? How I can solve this issue?
Cheers!
--
Regards!*
-
**Lolitha Ratnayake,
*

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Hi group

[Ken Wallis]

Welcome Piotr!
--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Piotr Zalewa [pzal...@mozilla.com]
Sent: Tuesday, June 11, 2013 12:44 AM
To: dev@cordova.apache.org
Subject: Hi group

Hi,

I've been following the group for some time, however kept quiet.
I'm working for Mozilla and I've been asked to help with porting Cordova to 
FirefoxOS.

You may know me from few projects I've created (JSFiddle being probably most 
known to you).
My latest and not finished project at Mozilla is Kitchensink - a webapp which 
tests APIs.

I am a noob to Cordova and will hit probably quite a few trivial blockers. I am 
on the #cordova channel as zalun.

Piotr

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Hello World!

[Ken Wallis]

Welcome to the group Lisa!

I do have to ask, have you looked at the new BlackBerry's?

Sent from my BlackBerry 10 smartphone.
From: Tommy Williams
Sent: Monday, June 10, 2013 2:04 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: Hello  World!


Welcome, Lisa.

As for the phone, I just picked up a Nexus 4 yesterday. Can't go wrong with
"pure" Android as Google intended...
On 11 Jun 2013 02:28, "Lisa Seacat DeLuca"  wrote:

> I've been following the Cordova mailing lists and contributing fixes back
> into the mobile tech spec and docs for about a month now but wanted to send
> a quick note to introduce myself. I work for IBM and am part of our
> emerging internet technologies standards and strategy organization. I've
> been tasked with helping out with Cordova for the immediate future. As
> Carlos mentioned last week, I am working with a small group of IBMers
> contributing to Cordova. I've written a few Cordova apps (back when it was
> known as phonegap) and generally love working with mobile, html, css, and
> JavaScript. My expertise is more on the Java side. Fil suggested I
> introduce myself to everyone... so HELLO! Check out my website
> www.lisaseacat.com for more information on my technical skills. Feel
> free to reach out to me. Looking forward to getting to know you all.
>
> Oh, and I'm due a "new every 2" for Verizon here on the 20th... any
> suggestions for an Android phone?!?
>
>
> Lisa
>
>
> *Lisa Seacat DeLuca*
> Emerging Mobile Software Engineer - IBM Master Inventor
> SWG Emerging Internet Standards
> --
> *Phone:* 1-410-332-2128 | *Mobile:* 1-415-787-4589*
> E-mail:* *ldel...@us.ibm.com* *
> personal website: **lisaseacat.com* *
> Chat:*[image: Sametime:] ldel...@us.ibm.com *
> Find me on:* [image: LinkedIn: 
> http://www.linkedin.com/in/lisaseacat]
> [image: Twitter: https://twitter.com/IBMlisa]
> *and within IBM on:* [image: IBM Connections:
> https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0]
>
> [image: IBM]
>
> 100 East Pratt St 21-2212
> Baltimore, MD 21202-1009
> United States
>
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: meet up in SF next week (June 9-14)?

[Ken Wallis]

I'd be in for something.

Sent from my BlackBerry Z10 smartphone
From: John M. Wargo
Sent: Thursday, June 6, 2013 4:39 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: meet up in SF next week (June 9-14)?


I'll be there too, but not for the WWDC, i'll be attending the MIT Technology 
Review Mobile Summit.

On 6/6/2013 10:58 AM, Brian LeRoux wrote:
> Yup I'm around too (tho not at WWDC). Maybe an informal cordova dinner
> is in order?
>
>
> On Thu, Jun 6, 2013 at 1:30 AM, Shazron  wrote:
>> Hi James, I will be at WWDC next week, let's meet up. Feel free to drop by
>> the Adobe SF office as well :)
>> (although its not exactly near Moscone West)
>>
>>
>> On Wed, Jun 5, 2013 at 8:42 AM, James Jong  wrote:
>>
>>> I was able to get a late ticket to go to WWDC so I'll be in SF next week.
>>> Anyone else here going and want to meet up? Perhaps we can get together
>>> one evening? All those around welcome, not limited to those going to WWDC.
>>>
>>> -James Jong
>>>
>>>


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Alias of BB create tools

[Ken Wallis]

Wow, we are all on the ball right now... ;)
--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Bryan Higgins [br...@bryanhiggins.net]
Sent: Tuesday, June 04, 2013 2:39 PM
To: dev@cordova.apache.org
Subject: Re: Alias of BB create tools

We also recently added "globalFetchDir" which allows you to install a
plugin using the platform plugin script without specifying the full path.

In my opinion, default target should be global as well.


On Tue, Jun 4, 2013 at 5:37 PM, Lorin Beer  wrote:

> the json file currently contains
>
> 1. string to name bar file
> 2. path to find bb10 plugins
> 3. default target
> 4. all targets currently created
>
> list of registered targets would mean we could make finding and
> registering devices on the onus of the user, making several CLI
> scripts trivial rather than impossible (vm related scripts for
> instance).
>
> As Bryan suggests, project name gets moved to config.xml, along with
> maybe default target?
>
> On Tue, Jun 4, 2013 at 2:31 PM, Ken Wallis  wrote:
> > +1 here as well.
> >
> > what else is in the JSON file, and what scripts are related to that
> additional information if any?
> > --
> >
> > Ken Wallis
> >
> > Product Manager – WebWorks
> >
> > BlackBerry
> >
> > 289-261-4369
> >
> > 
> > From: Bryan Higgins [br...@bryanhiggins.net]
> > Sent: Tuesday, June 04, 2013 2:30 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Alias of BB create tools
> >
> > +1
> >
> > I'd like to see the entire JSON file moved out of the project. It's meant
> > to be for environment specific settings.
> >
> > barName should get moved into config.xml
> >
> >
> > On Tue, Jun 4, 2013 at 5:24 PM, Filip Maj  wrote:
> >
> >> Fil likes.
> >>
> >> On 6/4/13 2:21 PM, "Lorin Beer"  wrote:
> >>
> >> >Something I've wanted to do for a while with the BB repos:
> >> >
> >> >alias the target add script which is currently a project level script
> >> >into the root /bin
> >> >the purpose of this would be to allow users to create device targets
> >> >from the repo, which would then be propagated to individual projects.
> >> >
> >> >This has two advantages I can see:
> >> >
> >> >1. you no longer have to re-create targets or copy the .json file over
> >> >when creating new BB10 projects
> >> >
> >> >2. by making target create a repo level script, we can fully support
> >> >more of the CLI scripts
> >> >
> >> >What does BB think?
> >>
> >>
> >
> > -
> > This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Alias of BB create tools

[Ken Wallis]

I agree with project name to config.xml.

I think default target remains with the list of targets in JSON.  Same with 
path to plugins.  And in this context, I think the JSON could go out to the 
root.
--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Lorin Beer [lorin.beer@gmail.com]
Sent: Tuesday, June 04, 2013 2:37 PM
To: dev
Subject: Re: Alias of BB create tools

the json file currently contains

1. string to name bar file
2. path to find bb10 plugins
3. default target
4. all targets currently created

list of registered targets would mean we could make finding and
registering devices on the onus of the user, making several CLI
scripts trivial rather than impossible (vm related scripts for
instance).

As Bryan suggests, project name gets moved to config.xml, along with
maybe default target?

On Tue, Jun 4, 2013 at 2:31 PM, Ken Wallis  wrote:
> +1 here as well.
>
> what else is in the JSON file, and what scripts are related to that 
> additional information if any?
> --
>
> Ken Wallis
>
> Product Manager – WebWorks
>
> BlackBerry
>
> 289-261-4369
>
> 
> From: Bryan Higgins [br...@bryanhiggins.net]
> Sent: Tuesday, June 04, 2013 2:30 PM
> To: dev@cordova.apache.org
> Subject: Re: Alias of BB create tools
>
> +1
>
> I'd like to see the entire JSON file moved out of the project. It's meant
> to be for environment specific settings.
>
> barName should get moved into config.xml
>
>
> On Tue, Jun 4, 2013 at 5:24 PM, Filip Maj  wrote:
>
>> Fil likes.
>>
>> On 6/4/13 2:21 PM, "Lorin Beer"  wrote:
>>
>> >Something I've wanted to do for a while with the BB repos:
>> >
>> >alias the target add script which is currently a project level script
>> >into the root /bin
>> >the purpose of this would be to allow users to create device targets
>> >from the repo, which would then be propagated to individual projects.
>> >
>> >This has two advantages I can see:
>> >
>> >1. you no longer have to re-create targets or copy the .json file over
>> >when creating new BB10 projects
>> >
>> >2. by making target create a repo level script, we can fully support
>> >more of the CLI scripts
>> >
>> >What does BB think?
>>
>>
>
> -
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute non-public 
> information. Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this transmission in error, 
> please immediately reply to the sender and delete this information from your 
> system. Use, dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and may be unlawful.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Alias of BB create tools

[Ken Wallis]

+1 here as well.

what else is in the JSON file, and what scripts are related to that additional 
information if any?
--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Bryan Higgins [br...@bryanhiggins.net]
Sent: Tuesday, June 04, 2013 2:30 PM
To: dev@cordova.apache.org
Subject: Re: Alias of BB create tools

+1

I'd like to see the entire JSON file moved out of the project. It's meant
to be for environment specific settings.

barName should get moved into config.xml


On Tue, Jun 4, 2013 at 5:24 PM, Filip Maj  wrote:

> Fil likes.
>
> On 6/4/13 2:21 PM, "Lorin Beer"  wrote:
>
> >Something I've wanted to do for a while with the BB repos:
> >
> >alias the target add script which is currently a project level script
> >into the root /bin
> >the purpose of this would be to allow users to create device targets
> >from the repo, which would then be propagated to individual projects.
> >
> >This has two advantages I can see:
> >
> >1. you no longer have to re-create targets or copy the .json file over
> >when creating new BB10 projects
> >
> >2. by making target create a repo level script, we can fully support
> >more of the CLI scripts
> >
> >What does BB think?
>
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Widening the window (was: The Deprecation of Froyo)

[Ken Wallis]

I completely understand this argument, but there is one angle that makes this 
very murky, and I think talks mostly to Marcel's argument: Enterprise.

I deal with this everyday, trying to get any sort of metric around Enterprise 
apps.  It is almost impossible.  But the anecdotal evidence from our enterprise 
support teams is that there are a LOT of enterprise apps, a LOT of which are 
using HTML5, there is huge interest in Cordova/PhoneGap, and these are apps 
that you are really never going to know about.

If the only thing we look at is the public app stores, then we are really only 
focusing the Cordova effort on Consumers and consumer apps.  Enterprise is a 
different beast, but I think should be considered a very important beast for 
this community.


--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Joe Bowser [bows...@gmail.com]
Sent: Friday, May 31, 2013 12:14 PM
To: dev
Subject: Re: Widening the window (was: The Deprecation of Froyo)

On Fri, May 31, 2013 at 2:43 PM, Marcel Kinard  wrote:
> Starting off, specifically, I'm asking if we can keep Android 2.2 in Cordova 
> head. For how long? Until the OS usage in these markets drops into the 
> "doesn't matter" threshold. I suspect that will not be just a few months. And 
> does the definition of "keep" mean "actively support" or "just avoid breaking 
> it"? I'm open to suggestions. If I'm the only person asking for this, I 
> understand I need to have some skin in the game.
>

No.

In fact, I'll say hell no. We base our deprecation of Android
platforms on the good old Android Pie Chart found at
https://developer.android.com/about/dashboards/index.html.  The pie
chart shows which people actually download applications on the Play
Store.  I don't care about Android 2.2 devices that don't connect to
the store because they don't connect to the store and Cordova isn't
distributed to these people.  These people don't matter because they
don't use apps, whether it be Cordova or a native Android application.
 Supporting users who will never use apps is insane!

Now, the Chinese market was problematic until recently, because Play
was blocked until a month or so ago.  That being said, I think the
Android Pie Chart is a very solid way to tell whether the version
matters or not because these are the people who download apps.  In
fact, if I was an application developer, I'd want to know about the
people who actually buy apps and in-app items, and what they run, and
I wouldn't support any of the freeloaders.  That's where the group of
android developers who tweet about minApiLevel=14 come from.

If we don't use the Android Pie Chart to determine what to support,
what do we use? Stories from the guy who hasn't upgraded their phone
in years? The fact is that the store is the only real way that we can
have any metrics on people who actually use apps, including people who
use Cordova apps.

Finally, one of the big problems with supporting old versions for so
long is maintaining old devices.  Devices eventually break.  When you
install and uninstall something on a phone enough times, things get
weird, and even when you factory reset the device, things tend to not
work the same after three years of testing.  We have one Android 2.1
device and one Android 2.2 device.  They tend to not work on the
device wall for some weird reason, and it's time consuming to run
mobile-spec on them such that it's not a worthwhile use of time to
actually make sure that we don't break Android 2.1 and 2.2 in the real
world.  When is the last time anyone else who works on Android tested
on Froyo?  Does anyone remember the last time they tested Eclair when
we claimed to support that?  The emulator doesn't count!

So, no, I see zero value in extending our deprecation window larger
than it currently is.  We should support users who actually use apps,
not people who don't.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Baby Grieve

[Ken Wallis]

Great news, and best wishes to you and the family!

Sent from my BlackBerry Z10 smartphone
From: Andrew Grieve
Sent: Friday, May 31, 2013 7:01 AM
To: dev
Reply To: dev@cordova.apache.org
Subject: Baby Grieve


Coming 1 month early

Everett Arend Grieve born Thursday May 30 at 9:45 am. 5 lbs 15 oz. 18.5 inches 
long.

Mom is currently in the ACOU and Everett in the ICU. They are on track to meet 
today! We will be a few days in the hospital, but everything's looking good!

Not sure how much I'll be checking email in the next little while. Good luck 
with the release!

Andrew


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Introduction

[Ken Wallis]

Good to be working with you again! Welcome.

--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: John Wargo [jwarg...@gmail.com]
Sent: Wednesday, May 29, 2013 4:52 AM
To: dev@cordova.apache.org
Subject: Introduction

Hello, my name is John Wargo - I'm the author of PhoneGap Essentials 
(www.phonegapessentials.com) and I'm working on an update to the book which 
will be out later this year. I will have some questions related to the 
direction the project is taking and how some of the stuff is supposed to work. 
I just wanted to introduce myself to the list.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: new committer: Bryan Higgins

[Ken Wallis]

Congratulations!

Sent from my BlackBerry Z10 smartphone
From: Lorin Beer
Sent: Monday, May 20, 2013 11:39 AM
To: dev
Reply To: dev@cordova.apache.org
Subject: new committer: Bryan Higgins


The Project Management Committee (PMC) for Apache Cordova
has asked Bryan Higgins to become a committer and we are pleased
to announce that they have accepted.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: new committer: Benn Mapes

[Ken Wallis]

Congratulations!

Sent from my BlackBerry Z10 smartphone
From: Lorin Beer
Sent: Monday, May 20, 2013 11:38 AM
To: dev
Reply To: dev@cordova.apache.org
Subject: new committer: Benn Mapes


The Project Management Committee (PMC) for Apache Cordova
has asked Benn Mapes to become a committer and we are pleased
to announce that they have accepted.

Being a committer enables easier contribution to the
project since there is no need to go via the patch
submission process. This should enable better productivity.
Being a PMC member enables assistance with the management
and to guide the direction of the project.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Cordova BlackBerry project structure

[Ken Wallis]

Yup

--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Bryan Higgins [br...@bryanhiggins.net]
Sent: Wednesday, May 15, 2013 10:51 AM
To: dev@cordova.apache.org
Subject: Re: Cordova BlackBerry project structure

works for me


On Wed, May 15, 2013 at 1:49 PM, Brian LeRoux  wrote:

> like it
>
> On Wed, May 15, 2013 at 8:39 AM, Lorin Beer 
> wrote:
> > I like blackberryOS, that work for everybody?
> >
> > to cut down on redundant naming:
> >
> > cordova-blackberry/bbos
> > cordova-blackberry/playbook
> > cordova-blackberry/bb10
> >
> >
> > On Wed, May 15, 2013 at 5:38 AM, Bryan Higgins  >wrote:
> >
> >> +1
> >>
> >> Except the name for the BBOS folder doesn't capture support for OS5&6.
> Can
> >> we name it blackberry5-7 or blackberryOS ?
> >>
> >>
> >> On Tue, May 14, 2013 at 6:58 PM, Lorin Beer  >> >wrote:
> >>
> >> > that's my idea, Jeffrey, to route to sub platform bin scripts. The
> >> original
> >> > create tool would create a project which could target any blackberry
> >> > platform, not just one. The idea would be that the root bin calls the
> >> > platform bin scripts and creates a single project again which can
> target
> >> > the individual platforms.
> >> >
> >> > The only item that requires appreciable work is the root bin folder,
> we
> >> can
> >> > scope what that would require separately.
> >> >
> >> >
> >> >
> >> > On Tue, May 14, 2013 at 3:35 PM, Jeffrey Heifetz <
> >> jheif...@blackberry.com
> >> > >wrote:
> >> >
> >> > > If bin is top level, it requires a non-standard first parameter to
> >> > > distinguish sub-platform. I know this is the same as the old way,
> but
> >> > it's
> >> > > very unique to the BlackBerry implementation.
> >> > >
> >> > > Perhaps if this just routed to sub platform bin scripts it would be
> >> > ideal.
> >> > >
> >> > > Sent from my BlackBerry 10 smartphone on the Rogers network.
> >> > > From: Ken Wallis
> >> > > Sent: Tuesday, May 14, 2013 6:21 PM
> >> > > To: dev@cordova.apache.org; dev
> >> > > Reply To: dev@cordova.apache.org
> >> > > Subject: Re: Cordova BlackBerry project structure
> >> > >
> >> > >
> >> > > +1
> >> > >
> >> > > Sent from my BlackBerry Z10 smartphone
> >> > > From: Lorin Beer
> >> > > Sent: Tuesday, May 14, 2013 6:17 PM
> >> > > To: dev
> >> > > Reply To: dev@cordova.apache.org
> >> > > Subject: Re: Cordova BlackBerry project structure
> >> > >
> >> > >
> >> > > ok, final word on this is to not break out the BlackBerry platforms
> >> into
> >> > > separate repos. However, they will break out into subdirectories in
> the
> >> > > root of the blackberry repo:
> >> > >
> >> > > apache/cordova-blackberry/blackberry7
> >> > > apache/cordova-blackberry/blackberry10
> >> > > apache/cordova-blackberry/playbook
> >> > > apache/cordova-blackberry/bin
> >> > >
> >> > > bin will provide a uniform tooling interface for creating projects,
> >> just
> >> > a
> >> > > simple shim script to delegate to the platform tool scripts, which
> have
> >> > > diverged.
> >> > >
> >> > > This means duplicating the playbook/bb7 scripts, but bb7 will be
> >> removed
> >> > by
> >> > > 3.0, so this is a short term duplication.
> >> > >
> >> > >
> >> > > I think this solution minimizes the amount of work while adopting a
> >> > project
> >> > > structure that makes the most sense for our developers.
> >> > >
> >> > > vote now or forever hold your peace.
> >> > >
> >> > > - Lorin
> >> > >
> >> > >
> >> > >
> >> > > On Fri, May 10, 2013 at 10:09 AM, Brian LeRoux  wrote:
> >> > >
> >> > > > yes, exactly that
> >> > > >
> >> > > > On Fri, May 10, 2013 at 9:39 AM, Lorin Beer <
> >> lorin.bee

Re: Cordova BlackBerry project structure

[Ken Wallis]

+1

Sent from my BlackBerry Z10 smartphone
From: Lorin Beer
Sent: Tuesday, May 14, 2013 6:17 PM
To: dev
Reply To: dev@cordova.apache.org
Subject: Re: Cordova BlackBerry project structure


ok, final word on this is to not break out the BlackBerry platforms into
separate repos. However, they will break out into subdirectories in the
root of the blackberry repo:

apache/cordova-blackberry/blackberry7
apache/cordova-blackberry/blackberry10
apache/cordova-blackberry/playbook
apache/cordova-blackberry/bin

bin will provide a uniform tooling interface for creating projects, just a
simple shim script to delegate to the platform tool scripts, which have
diverged.

This means duplicating the playbook/bb7 scripts, but bb7 will be removed by
3.0, so this is a short term duplication.


I think this solution minimizes the amount of work while adopting a project
structure that makes the most sense for our developers.

vote now or forever hold your peace.

- Lorin



On Fri, May 10, 2013 at 10:09 AM, Brian LeRoux  wrote:

> yes, exactly that
>
> On Fri, May 10, 2013 at 9:39 AM, Lorin Beer 
> wrote:
> > that confused me too,
> >
> > windows phone already has separate repos. apache/wp7 and apache/wp8. If
> we
> > stick with the "os vendor" organization, should we refactor those repos
> > into a single "windowsphone" repo?
> >
> >
> >
> > On Fri, May 10, 2013 at 9:09 AM, Filip Maj  wrote:
> >
> >> Which repos would need refactoring, Brian?
> >>
> >> On 5/9/13 2:56 PM, "Brian LeRoux"  wrote:
> >>
> >> >I'm a no on this. Conceptually grouping by operating system vendor
> >> >makes more sense (to me). If we're going down this path the other
> >> >repos need to be refacored to reflect it: cordova-platform-* (and
> >> >Windows will need breaking out).
> >> >
> >> >(Also I'm not a fan of mixing pascal case with camel case but thats a
> >> >separate issue!)
> >> >
> >> >On Thu, May 9, 2013 at 10:50 AM, Lorin Beer 
> >> >wrote:
> >> >> Currently, BlackBerry exists as a single repository containing 3
> >> >>different
> >> >> implementations of Cordova: BB7, PlayBook and BB10.
> >> >>
> >> >> This has been great from a user perspective: the cordova create tool
> >> >> allowed you to specify which target you wanted to build/run to once a
> >> >> project has been created.
> >> >>
> >> >> However, BlackBerry has split the new BB10 implementation off from
> the
> >> >> previous project structure: it now lives in a separate tree, and runs
> >> >>with
> >> >> it's own implementation of the tools.
> >> >>
> >> >> With the decision to send BB7 off to the farm getting positive
> >> >>feedback, I
> >> >> want to reopen the discussion of BlackBerry's project structure.
> >> >>
> >> >> Proposition:
> >> >> split the BB platform implementations, with 3 repositories:
> >> >> apache/Cordova-BlackBerry7
> >> >> apache/Cordova-BlackBerryPlaybook
> >> >> apache/Cordova-BlackBerry10
> >> >>
> >> >> we let the CLI provide the uniform interface between platforms, and
> >> >>treat
> >> >> these as separate implentations. It also gets ahead of the work to
> drop
> >> >>BB7
> >> >> and avoids o "re-integrate" task for BB10 which sounds like a waste
> of
> >> >>time.
> >> >>
> >> >> - Lorin
> >>
> >>
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: blackberry 10 migration

[Ken Wallis]

Thanks Lorin.  Exciting times for us to see this in Apache. ;)

--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Lorin Beer [lorin.beer@gmail.com]
Sent: Tuesday, May 07, 2013 8:26 AM
To: dev
Subject: Re: blackberry 10 migration

pulled into apache:

github.com/blackberry/
  cordova-blackberry to future branch
  cordova-js to future branch
  cordova-cli to apache future-bb10 branch
  cordova-plugman to apache future branch


spoke briefly with Anis concerning merging into plugman and cli, this will
likely wait until Fil Maj is back from Max. The plugman changes seem to be
orthogonal to the master/future branch (ie non-breaking).

as for cordova-js and cordova-blackberry, plan is to merge those as soon as
docs are in place.

It can take a few hours for the github mirrors to catch up to git-apache,
but retarget those pull requests anytime.


On Mon, May 6, 2013 at 4:32 PM, Lorin Beer  wrote:

> will do
>
>
> On Mon, May 6, 2013 at 4:23 PM, Bryan Higgins wrote:
>
>> Ok, I'm about to merge from blackberry/blackberry10-rebase into
>> blackberry/blackberry10
>>
>> Let me know when you have pushed into apache. There are some open pull
>> requests which I will re-target.
>>
>>
>> On Mon, May 6, 2013 at 7:07 PM, Jeffrey Heifetz > >wrote:
>>
>> > What about plugman and cli?
>> >
>> > Sent from my BlackBerry 10 smartphone on the Rogers network.
>> > From: Lorin Beer
>> > Sent: Monday, May 6, 2013 7:04 PM
>> > To: dev
>> > Reply To: dev@cordova.apache.org
>> > Subject: Re: blackberry 10 migration
>> >
>> >
>> > ok, we'll pull the code from Blackberry/Blackberry-Cordova and
>> > Blackberry/Cordova-JS into branches in the apache repos. When the docs
>> are
>> > ready, we'll merge them into master.
>> >
>> > On Mon, May 6, 2013 at 3:36 PM, Bryan Higgins > > >wrote:
>> >
>> > > Hi Lorin,
>> > >
>> > > That's great. I think we should be able to get out a rough draft over
>> the
>> > > next couple days.
>> > >
>> > >
>> > > On Mon, May 6, 2013 at 1:43 PM, Lorin Beer 
>> > > wrote:
>> > >
>> > > > Hi Bryan, a quick update:
>> > > >
>> > > > I'll be pulling the code in as soon as docs are in place. Let me
>> know
>> > > when
>> > > > you can push a rough draft at us!
>> > > >
>> > > > - Lorin
>> > > >
>> > > >
>> > > > On Fri, May 3, 2013 at 9:43 AM, Lorin Beer <
>> lorin.beer@gmail.com>
>> > > > wrote:
>> > > >
>> > > > > sounds awesome! Brian is trying to set up a meetings with our
>> teams
>> > > next
>> > > > > week after Max, so I think we are pushing for a post-Max migration
>> > > date,
>> > > > > late next week.
>> > > > >
>> > > > > thanks for the update Bryan,
>> > > > >
>> > > > > Lorin
>> > > > >
>> > > > >
>> > > > > On Fri, May 3, 2013 at 5:24 AM, Bryan Higgins <
>> > bhigg...@blackberry.com
>> > > > >wrote:
>> > > > >
>> > > > >> Hi Lorin,
>> > > > >>
>> > > > >> We will update to 2.7.0 today and I'm meeting with the docs
>> people
>> > > this
>> > > > >> afternoon.
>> > > > >>
>> > > > >> If they don't have anything ready, I can bang out a draft while
>> I'm
>> > > > flying
>> > > > >> out to Max on Sunday.
>> > > > >>
>> > > > >> Thanks,
>> > > > >> Bryan
>> > > > >>
>> > > > >>
>> > > > >> On Thu, May 2, 2013 at 5:45 PM, Lorin Beer <
>> > lorin.beer@gmail.com>
>> > > > >> wrote:
>> > > > >>
>> > > > >> > Hi Bryan,
>> > > > >> >
>> > > > >> > any progress on the doc side of things? From my experience with
>> > the
>> > > > new
>> > > > >> > codebase, I shouldn't think that documenting the necessary
>> > workflows
>> > > > >> > (plugins, getting started, etc) should be too time consumin

BlackBerry Jam conference in Orlando

[Ken Wallis]

Hey everyone, our annual America's developer conference is May 14-16 in sunny, 
fun Orlando, FL! If anyone is interested in attending, let me know offline at 
kwallis.at.blackberry.dot.com

I might be able to swing hotel for the three nights and a comp pass if you get 
back to me soon.

And everyone that registers gets a shiny brand new Z10!

We'll have a bunch of sessions on Web for BlackBerry 10 and a session on our 
new, Cordova focused direction.




Sent from my BlackBerry Z10 smartphone on the Bell network.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Naming: cordova-2.8.0.js --> cordova.js

[Ken Wallis]

+1. We moved away from that in WebWorks a while back and just had the packaging 
tool copy in the compatible version.

Sent from my BlackBerry Z10 smartphone on the Bell network.
From: Michael Brooks
Sent: Tuesday, April 30, 2013 1:36 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: Naming: cordova-2.8.0.js --> cordova.js


+1 cordova.js with version as a header comment


On Tue, Apr 30, 2013 at 11:31 AM, Filip Maj  wrote:

> If I recall correctly the original reason was because putting the version
> in after the lib name in the JS filename was what "other libraries did"
> aka jQuery.
>
> +1 from me.
>
> On 4/30/13 11:24 AM, "tommy-carlos Williams"  wrote:
>
> >+1
> >
> >Wouldn't this make mobile spec easier too?
> >
> >On 01/05/2013, at 4:20, Andrew Grieve  wrote:
> >
> >> This has been brought up a few times, but I'm not sure there's been a
> >> decisive answer here yet...
> >>
> >> iOS now uses "cordova.ios.js"
> >> Android uses "cordova.android.js", but renames it in a build step to
> >>add in
> >> the version number.
> >> CLI normalizes to "cordova.js"
> >>
> >> The version number is now stamped at the top of the file in a code
> >>comment,
> >> and I feel that having it in the file name just makes work for us and
> >>our
> >> users. I'd like to change all repos to just use "cordova.js".
> >>
> >> Any objections?
> >>
> >> Andrew
>
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Invite your friends and colleagues to the Tizen Conference

[Ken Wallis]

Thanks very much for this Paul, I will be attending.  Any other Cordova people 
going, perhaps an informal gathering can be arranged?

--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Plaquette, Paul [paul.plaque...@intel.com]
Sent: Monday, April 22, 2013 12:22 PM
To: dev
Subject: Fwd: Invite your friends and colleagues to the Tizen Conference

Hi folks,

As you may know the 2nd edition of  Tizen Developer Conference for 2013
 will be held  in San Francisco in May 22-24.

In case  some would like to attend here is a 75 % discount  I received as a
speaker to invite friends . (see the link  in the mail forwarded below)

By the way, i will give there a talk on Cordova on Tizen  Magnolia (v 2.0
SDK).

By the way, the adaptation of existing code for Tizen 1.0 to Tizen SDK 2.0
(Magnolia ) is doing pretty well  (and should be ready the time to deal
with "internal publishing policies at Intel" ;-)  )

Cordially,
Paul


Paul Plaquette,
Senior Software Engineer
Intel Corporation SAS *
*
*SSG/SSD/Open Source Technology Center*
France, Montpellier



-- Forwarded message --
From: Tizen Conference 2013 
Date: Mon, Apr 15, 2013 at 6:01 AM
Subject: Invite your friends and colleagues to the Tizen Conference
To: paul.plaque...@intel.com


Thank you for confirming to be a speaker at the Tizen Developer Conference
2013!

 We are very excited for you to join, and we would like to offer your
friends a discount to attend.

 You may pass along the following code and link for a 75% discount:

 Code: TSPFD13
https://www.eiseverywhere.com/tizenconf2013?discountcode=TSPFD13

 -
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: BlackBerry BB10 Repos on GitHub

[Ken Wallis]

To a degree I think the architecture has been simplified.  Was not the Cordova 
APIs calling to WebWorks apis, which then hit native, whereas now we don't have 
the WebWorks layer?
--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: chris.del...@gmail.com [chris.del...@gmail.com] on behalf of Chris DelCol 
[cdel...@blackberry.com]
Sent: Monday, April 08, 2013 10:15 AM
To: dev@cordova.apache.org
Subject: Re: BlackBerry BB10 Repos on GitHub

I think the biggest impact is that the architecture and features of Cordova
are now implemented directly, rather than through a proprietary SDK that is
"somewhat" aligned. I'm not sure there will be actual performance gains, or
that the architecture is easier. But what it does mean is that
compatibility should go way up, and focus on it will go up as well since we
are not split between 2 competing products.


On Mon, Apr 8, 2013 at 12:09 PM, Michal Mocny  wrote:

> This sounds pretty cool.
>
> For those with no prior BB experience, is there a high level summary of the
> net effect of the changes?  x% faster exec, N less bytes of binary, Y
> timesr
> easier plugin development etc?
>
> Thanks,
> -Michal
>
>
> On Mon, Apr 8, 2013 at 11:22 AM, Bryan Higgins  >wrote:
>
> > It's exactly the same as this extension, but we've converted it into a
> > cordova plugin. We'll provide both the source and pre-compiled libraries.
> >
> >
> https://github.com/blackberry/BB10-WebWorks-Framework/tree/master/ext/jpps
> >
> >
> > On Mon, Apr 8, 2013 at 10:57 AM, Lorin Beer  > >wrote:
> >
> > > sounds great Bryan,
> > >
> > > about the private native dependency, is that provided as a precompiled
> > > library?
> > > Can we run these codes?
> > >
> > > - Lorin
> > >
> > >
> > > On Mon, Apr 8, 2013 at 7:13 AM, Bryan Higgins  > > >wrote:
> > >
> > > > Sounds good! There are still a few things we need to finish up to get
> > > test
> > > > results in line with the existing implementation. File API is the big
> > > one.
> > > >
> > > > There is also a native library needed which is in the private repo
> > right
> > > > now. We'll look at moving that into cordova-blackberry.
> > > >
> > > >
> > > > On Mon, Apr 8, 2013 at 9:52 AM, Lorin Beer  >
> > > > wrote:
> > > >
> > > > > Great! Last week, I wrote a little script to provide unique tags to
> > the
> > > > > unit tests in mobile spec. Once those are tagged, I'll be pushing
> up
> > > the
> > > > > currently failing tests in the existing BB10 implementation. Having
> > > those
> > > > > tests documented will hopefully provide an anchor to move the
> > > discussion
> > > > > forward.
> > > > >
> > > > >
> > > > > On Mon, Apr 8, 2013 at 5:57 AM, Bryan Higgins <
> > bhigg...@blackberry.com
> > > > > >wrote:
> > > > >
> > > > > > I'll follow up today with that. There are a few people who need
> to
> > > sign
> > > > > > still.
> > > > > >
> > > > > >
> > > > > > On Sun, Apr 7, 2013 at 6:32 PM, Lorin Beer <
> > lorin.beer....@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > This is great stuff! I figured we'd be waiting for a while
> > longer,
> > > > > great
> > > > > > to
> > > > > > > see this go live!
> > > > > > > Tim and I will be going through this right away.
> > > > > > > Bryan, I know you are on the
> > > > > > > list<
> https://people.apache.org/committer-index.html#unlistedclas
> > >;
> > > > has
> > > > > > > the rest of your team signed the Apache CLA as well?
> > > > > > >
> > > > > > > - Lorin
> > > > > > >
> > > > > > > On Sat, Apr 6, 2013 at 9:53 AM, Tim Kim 
> > > wrote:
> > > > > > >
> > > > > > > > Awesome!
> > > > > > > >
> > > > > > > >
> > > > > > > > On 6 April 2013 08:16, Ken Wallis 
> > > wrote:
> > > > > > > >
> > > > > > > > > So awesom

Re: BlackBerry BB10 Repos on GitHub

[Ken Wallis]

So awesome to see this go live, thanks Bryan. Looking forward to seeing 
progress towards this being merged into the Apache repos!

Sent from my BlackBerry Z10 smartphone.
From: Bryan Higgins
Sent: Saturday, April 6, 2013 6:42 AM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: BlackBerry BB10 Repos on GitHub


Over the last few weeks, we at BlackBerry WebWorks have been working on a
prototype for a new version of our SDK based on Cordova. I'm happy to say
that we're now able to share our repos publicly!

To understand what we've done, you will first need to understand that
WebWorks for BB10 is really 3 things:

  1.  Packager (bbwp) – a set of node scripts to assemble apps from source
  2.  Framework – handles bootstrap, extension loading, exec calls, events
  3.  Extensions – all of the APIs. Similar to cordova plugins, but
included in the SDK rather than directly in the project.

All of this is built on top of the "web platform" - a layer on top of
WebKit which exposes device APIs. We plan to document this layer and
provide instructions on how to build a web platform app using only the NDK.

For those wanting a rich set of APIs, we will provide a Cordova build along
with a set of custom plugins for platform features.

To get to that world, we need to move some logic from the packager and
framework into Cordova. This will really simplify the exec chain and ease
plugin development.

Old world:
Plugin script > cordova.exec > WebWorks extension > webworks.exec > web
platform / native

New world:
Plugin script > cordova.exec > web platform / native

All of our repos are up at github.com/blackberry. Here's a quick summary of
what we have done so far.

https://github.com/blackberry/cordova-blackberry

  *   split out BB10 from BBOS/PlayBook
  *   Re-implemented cordova create, build and run in node, using libs from
our packager
  *   Introduced "target" script for managing device and simulator
configuration
  *   Started the process of converting core plugins from wrappers to
calling web platform directly

https://github.com/blackberry/cordova-js

  *   Created blackberry10 as a top level platform
  *   Added some bootstrap, exec and event logic from our Framework
  *   Started the process of removing the wrappers (at which point
cordova.exec and webworks.exec are merged and webworks events will go away)

https://github.com/blackberry/cordova-plugman

  *   Copy "controller" code (index.js) and native .so files into the
project
  *   Implemented our prototype of script injection (wrapping js-modules in
cordova.define and generating plugins.json).

https://github.com/blackberry/cordova-cli

  *   Minor changes to support splitting out BB10 from BBOS

https://github.com/blackberry/cordova-blackberry-plugins (not yet public,)

  *   Plugins for BB10 platform features

I know this is a lot of dump on the list at once, but Jeff and I are here
to answer any questions or concerns. Now that the repos are live we'd like
to start a discussion on getting the code into Apache. We've got a small
team here working on this (intros to come) and everyone is excited to start
working with the community.

Cheers,
Bryan

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Introduction

[Ken Wallis]

Great to see you jumping in Erik!

Sent from my BlackBerry Z10 smartphone.
From: Lorin Beer
Sent: Friday, April 5, 2013 1:02 PM
To: dev
Reply To: dev@cordova.apache.org
Subject: Re: Introduction


Welcome Erik!


On Fri, Apr 5, 2013 at 12:07 PM, Max Woghiren  wrote:

> Welcome Lucas and Erik! Great to have you.
>
>
> On Fri, Apr 5, 2013 at 3:02 PM, Erik Johnson  >wrote:
>
> > I will piggy back on the back of Lucas's intro as well:
> >
> > Hey All,
> >
> > I'm Erik a dev at BlackBerry. I've been working on the WebWorks product
> in
> > some capacity for nearly a year now. I hope to be able to contribute as
> > well in some meaningful way. Feel free to forward me any BB specific
> fixes
> > that need to be done.
> >
> > Quick note: I've signed the CLA and have been parousing JIRA as well. My
> > first little project is creating the native support in our webview for
> > window.open with the menubar=true flag so we can support a menu bar less
> > experience in Oauth.
> >
> > -Erik
> > 
> > From: agri...@google.com [agri...@google.com] on behalf of Andrew
> Grieve [
> > agri...@chromium.org]
> > Sent: Friday, April 05, 2013 2:50 PM
> > To: dev
> > Subject: Re: Introduction
> >
> > Woohoo! Welcome!
> >
> >
> > On Fri, Apr 5, 2013 at 11:52 AM, Michal Mocny 
> wrote:
> >
> > > Welcome Lucas!
> > >
> > > Have you signed the Apache Contributor License Agreement?
> > >
> > > Be sure to check out
> http://wiki.apache.org/cordova/ContributorWorkflow
> > >
> > > -Michal
> > >
> > >
> > > On Fri, Apr 5, 2013 at 11:33 AM, Filip Maj  wrote:
> > >
> > > > Welcome Lucas!
> > > >
> > > > On 4/5/13 7:17 AM, "Lorin Beer"  wrote:
> > > >
> > > > >Hi Lucas, welcome to the dev list!
> > > > >
> > > > >You've got the right idea to get started, and if you have any
> > questions,
> > > > >drop it on the mailing list.
> > > > >
> > > > >- Lorin
> > > > >
> > > > >
> > > > >On Fri, Apr 5, 2013 at 7:11 AM, Lucas Holmquist <
> lholm...@redhat.com>
> > > > >wrote:
> > > > >
> > > > >> Hey all,
> > > > >>
> > > > >> i just wanted to introduce myself. I'm looking to start
> > contributing
> > > > >>and
> > > > >> helping out with the project. I mainly focus on JS, but can help
> in
> > > > >>others
> > > > >> areas as well.
> > > > >>
> > > > >> I'll take a look at the JIRA's to get started with. anything
> that i
> > > can
> > > > >> do to help, let me know
> > > > >>
> > > > >>
> > > > >> -Luke
> > > >
> > > >
> > >
> >
> > -
> > This transmission (including any attachments) may contain confidential
> > information, privileged material (including material protected by the
> > solicitor-client or other applicable privileges), or constitute
> non-public
> > information. Any use of this information by anyone other than the
> intended
> > recipient is prohibited. If you have received this transmission in error,
> > please immediately reply to the sender and delete this information from
> > your system. Use, dissemination, distribution, or reproduction of this
> > transmission by unintended recipients is not authorized and may be
> unlawful.
> >
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: BB10 and JIRA Etiquette

[Ken Wallis]

Sorry for the hold up guys. The dev team is pushing hard to get those 
particular GitHub repos opened ASAP so we can openly discuss it, and get that 
code moved in. A couple more things to check off and we will be good to go.

Thanks.

Sent from my BlackBerry Z10 smartphone.
From: Lorin Beer
Sent: Thursday, April 4, 2013 7:02 AM
To: dev
Reply To: dev@cordova.apache.org
Subject: Re: BB10 and JIRA Etiquette


Yeah, I've heard rumours of the ull rewrite, but until they actually start
showing their code and getting involved in the list discussion, I'm
pretending like we should proceed with BB10 dev on our end as normal.

Gord, any word on a timeframe for their involvement/contribution with
Apache Cordova?


On Thu, Apr 4, 2013 at 6:43 AM, Gord Tanner  wrote:

> The BlackBerry team has said on this list that they are rewriting
> everything for BlackBerry 10. They haven't shared any of the code yet but
> have warned that it is a complete rewrite. I am expecting it to be about
> the same support (or more).
>
> I think the issues are still valid as I can't imagine much changing when
> they rewrite everything.
>
> BlackBerry can chime in with more information.
>
>
> On Thu, Apr 4, 2013 at 6:10 AM, Lorin Beer 
> wrote:
>
> > I've started cataloguing the failing tests and missing functionality on
> > BB10.
> > There's about 50 failing tests, and many more missing features (minor and
> > major).
> >
> > What I'm wondering is this:
> > 1. dump all the issues in jira as I find them
> > or
> > 2. report the issues as I get an opportunity to fix them
> >
> > given the number of failing tests and issues, it would be some months
> > before I could get around to fixing all of them.
> >
> > On one hand, we get these issues documented so users see were aware of
> it,
> > and can indicate what they need fixed, not to mention encouraging others
> to
> > take on some of these issues.
> >
> > On the other hand, it'll bloat our issue count. :)
> >
> > Wondering what the best approach is.
> >
> > - Lorin
> >
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Work on the VHS api

[Ken Wallis]

Betamax is the future.

--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Joe Bowser [bows...@gmail.com]
Sent: Monday, April 01, 2013 11:32 AM
To: dev
Subject: Work on the VHS api

Hey

I really think that we should add this to Cordova ASAP.  Think we can
get it into the 2.6 release?

http://darktears.fr/vcr-api/Overview.html

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: [Android] Plugins to send on the ice flows to die

[Ken Wallis]

Thanks Shaz. I had thought that the Cordova Capture API was already based on 
the Media Capture spec, should have looked closer. ;)

Sent from my BlackBerry Z10 smartphone.
From: Shazron
Sent: Saturday, March 23, 2013 9:20 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: [Android] Plugins to send on the ice flows to die


Ken,
>From here: http://wiki.apache.org/cordova/Core%20API%20Audit
It will bring you eventually to here (Media Capture - getusermedia):
http://dev.w3.org/2011/webrtc/editor/getusermedia.html
and there's also HTML Media Capture:
http://www.w3.org/TR/html-media-capture/


On Fri, Mar 22, 2013 at 7:16 PM, Ken Wallis  wrote:

> What spec is that? I would like to research that, I was not aware there
> was a new one.
>
> Thanks!
>
> Sent from my BlackBerry Z10 smartphone.
> From: Shazron
> Sent: Friday, March 22, 2013 8:43 PM
> To: dev@cordova.apache.org
> Reply To: dev@cordova.apache.org
> Subject: Re: [Android] Plugins to send on the ice flows to die
>
>
> Andrew: Capture API. But that's going away I reckon as well (there is a new
> spec)
>
>
> On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve 
> wrote:
>
> > What's the alternative to Camera?
> >
> >
> > On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj  wrote:
> >
> > > +1 geo and websql deprecation
> > >
> > > I would wait on camera until we actually do the api audit
> > >
> > > On 3/22/13 2:54 PM, "Joe Bowser"  wrote:
> > >
> > > >Hey
> > > >
> > > >I'm currently looking through the plugins, and I'm thinking more and
> > > >more that Android has at least two plugins that I would like to see no
> > > >longer maintained once we break them off of the main repository.
> > > >
> > > >Geolocation:
> > > >---
> > > >Our Geolocation doesn't actually give us anything that the browser
> > > >doesn't do. I think that GPS could be done better, and that the spec
> > > >sucks. However our core plugins are supposed to follow the spec, and
> > > >since the browser on Android does this much better, there's no point
> > > >for this plugin to exist.
> > > >
> > > >WebSQL Storage:
> > > >
> > > >Our WebSQL storage is pretty brittle and is just a shim to the raw
> > > >SQLite that Android creates. There's no real exception handling, and
> > > >this could easily crash. I would like to deprecate this and point
> > > >people to a third party plugin if they need their SQLite done.
> > > >
> > > >Camera
> > > >--
> > > >Also, we need to figure out how we capture things. It'd be good if we
> > > >picked one way to do this over the other. Right now mobile-spec seems
> > > >to use the Camera API, which I don't think is correct. We need to
> > > >write a new test for this, because right now this isn't well tested.
> > > >I'd like to send the old Camera API on the ice flow in favour of
> > > >capture and the native URI handling.
> > > >
> > > >Thoughts on this?
> > > >
> > > >Joe
> > >
> > >
> >
>
> -
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: [Android] Plugins to send on the ice flows to die

[Ken Wallis]

What spec is that? I would like to research that, I was not aware there was a 
new one.

Thanks!

Sent from my BlackBerry Z10 smartphone.
From: Shazron
Sent: Friday, March 22, 2013 8:43 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: [Android] Plugins to send on the ice flows to die


Andrew: Capture API. But that's going away I reckon as well (there is a new
spec)


On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve  wrote:

> What's the alternative to Camera?
>
>
> On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj  wrote:
>
> > +1 geo and websql deprecation
> >
> > I would wait on camera until we actually do the api audit
> >
> > On 3/22/13 2:54 PM, "Joe Bowser"  wrote:
> >
> > >Hey
> > >
> > >I'm currently looking through the plugins, and I'm thinking more and
> > >more that Android has at least two plugins that I would like to see no
> > >longer maintained once we break them off of the main repository.
> > >
> > >Geolocation:
> > >---
> > >Our Geolocation doesn't actually give us anything that the browser
> > >doesn't do. I think that GPS could be done better, and that the spec
> > >sucks. However our core plugins are supposed to follow the spec, and
> > >since the browser on Android does this much better, there's no point
> > >for this plugin to exist.
> > >
> > >WebSQL Storage:
> > >
> > >Our WebSQL storage is pretty brittle and is just a shim to the raw
> > >SQLite that Android creates. There's no real exception handling, and
> > >this could easily crash. I would like to deprecate this and point
> > >people to a third party plugin if they need their SQLite done.
> > >
> > >Camera
> > >--
> > >Also, we need to figure out how we capture things. It'd be good if we
> > >picked one way to do this over the other. Right now mobile-spec seems
> > >to use the Camera API, which I don't think is correct. We need to
> > >write a new test for this, because right now this isn't well tested.
> > >I'd like to send the old Camera API on the ice flow in favour of
> > >capture and the native URI handling.
> > >
> > >Thoughts on this?
> > >
> > >Joe
> >
> >
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Platform-level command line scripts

[Ken Wallis]

Deploy vs. Emulate:  Deploy could be used to deploy to anything, emulator, 
ripple, simulator, or actual device.  I think perhaps deploy is the right 
terminology in this regard than emulate?

I agree with Jeff that it would be valuable to standardize arguments as well, 
in so far as those those that are common across platforms.
--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: agri...@google.com [agri...@google.com] on behalf of Andrew Grieve 
[agri...@chromium.org]
Sent: Wednesday, March 20, 2013 11:09 AM
To: dev
Subject: Re: Platform-level command line scripts

I like the suggestions of having fewer commands. Actually, why not have
just one command? It would make for less copy/paste, and you'd only have to
use a single --help to see what you can do.

E.g.:

./cordova/cli.js build --profile=release
./cordova/cli.js build --profile=debug
./cordova/cli.js clean
./cordova/cli.js package  // For app store
./cordova/cli.js log
./cordova/cli.js run --target=DEVICE_ID
./cordova/cli.js run --target=EMULATOR_ID
./cordova/cli.js run --target=ripple
./cordova/cli.js run --target=emulator
./cordova/cli.js run --target=emulator





On Wed, Mar 20, 2013 at 6:19 AM, Brian LeRoux  wrote:

> Fil: yes I like the easy wins you describe.
>
> Anis: agree on harder wins. The `emulate` cmd should require a
> parameter and only launch platform emulators.  The `run` cmd should
> default to Ripple, and while we're in there we should kill the serve
> command. Also agree, we should do a download to Fruitstrap from one of
> our forks (to be safe).
>
> Tommy: would be awesome to get your help on the `release` cmd for iOS.
>
> Jesse: agree about cordova-deploy tool should just deploy. (Only I
> think we should rename it to `emulate` and have it require a
> parameter.)
>
> Mapes: we hate the Bruins ok buddy? Get over it. Also: `build` cmd is
> for debug builds and `release` cmd is for doing release builds as you
> intuited. I think you got `run` and `emulate` mixed up but the spirit
> was correct.
>
> Tim/Bryan: can we kick up a fresh thread on the BB10 business? It
> would be nice to get that in but I think those queries got lost in
> this deluge.
>
> Axe! (Parashuram's online crime fighting persona is axemclion): thanks
> for saying hi, we'd love the help yo!
>
>
> On Wed, Mar 20, 2013 at 1:14 AM, Jesse MacFadyen
>  wrote:
> > Welcome Parashuram!
> > Happy to have some help. Benn has been working on most of this, and I
> > have created the deploy tools for wp7 and wp8, so reach out if you
> > need guidance or anything.
> >
> > Cheers,
> >   Jesse
> >
> > Sent from my iPhone5
> >
> > On 2013-03-19, at 10:24 PM, "Parashuram Narasimhan (MS OPEN TECH)"
> >  wrote:
> >
> > Hi,
> >
> > I could offer to start helping on the Windows Phone side of things.
> >
> > P.S: This is my first email to the group, and I think I should
> > introduce myself - I am Parashuram, working for Microsoft Open
> > Technologies Inc.
> >
> > -Original Message-
> > From: Filip Maj [mailto:f...@adobe.com]
> > Sent: Tuesday, March 19, 2013 3:42 PM
> > To: dev@cordova.apache.org
> > Subject: Platform-level command line scripts
> >
> > Bringing this up once more, hopefully the last time :)
> >
> > TL;DR: the behavior and naming of the platform-level scripts are still
> > not 100% lined up. I'd like to fix this and agree with you all on some
> > of the finer points surrounding this issue.
> >
> > Benn Mapes, an intern at Adobe, has been working on adding Windows
> > Phone support to cordova-cli. It's been a bit of work, but the first
> > step is to land command line scripts at the Windows Phone project
> > level, which he is actively working on. With this happening, I want to
> > make sure we have our base project-level CLI scripts sorted properly.
> >
> > Additionally, I've been seeing issues filed against the CLI with
> > essentially users being confused as to why the behavior of "cordova
> > build"
> > vs "cordova emulate" on different platforms is different [1] [2].
> >
> > The answer to all of this is that the project-level scripts have
> > slightly different behavior. I've looked into what each of Android,
> > iOS and BlackBerry (10) do and I've got a basic table sorted out
> > (below). I would like to get to an agreement on naming and behavior
> > for each, and ideally file issues to get as many of our platform
> > implementations as possible to implement/tweak behavior so that we are
> > consistent on this front.
> >
&g

Re: archiving older platforms

[Ken Wallis]

We will try to provide relevant stats on platform adoption as we are able. I am 
anxiously awaiting that information myself. ;)

While lacking this information, I still feel that BBOS will be with us for a 
deal of time, particularly in the enterprise where we are seeing a significant 
trend towards Cordova/PhoneGap/WebWorks as the primary platform of choice for 
apps. This is, frustratingly, a difficult market to get adequate metrics out 
of, as they will typically not use PhoneGap Build IMO, and they don't deploy to 
commercial application stores. A bit of a black box, but our enterprise support 
teams continually support the notion that enterprise looks at HTML5 apps first.

In this regard, we would like to see support for BBOS be maintained in the 
short term. Our team is focused on bringing up BlackBerry 10 built on Cordova, 
and once that has gotten to a stable point we will then be able to look at 
resources and determine if BBOS is still a valuable platform to support and if 
we can port BBOS to the new structures.

Hope that makes sense.

Sent from my BlackBerry Z10 smartphone.
From: Anis KADRI
Sent: Monday, March 18, 2013 1:00 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: archiving older platforms


s/QR/Qt


On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer wrote:

> +1 Bada/webOS/QR
>
> echoing Michael's point, I'd like to see usage stats on the older BB
> platforms. BB10 should absolutely be the focus, but If they are currently
> being used, mothballing may be premature. Revisiting the issues regularly,
> and making one based on usage stats makes the most sense to me.
>
>
> On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj  wrote:
>
> > +1 all of them, Java and Air implementations of BlackBerry as well.
> >
> > For the older implementations of BlackBerry, nothing is stopping anyone
> > from using that code. The fact is that Java and Air-related fixes have
> not
> > been going in regularly. The implementations are stable enough that
> > drawing a line in the sand and saying no more active support for the
> older
> > BB SDKs is acceptable in my opinion.
> >
> > On 3/17/13 11:44 AM, "Michael Brooks"  wrote:
> >
> > >>
> > >> As far as bb 6 and 7, I am sure the majority of devices out there are
> > >>BB 6
> > >> and 7. BB10 just came out so there can't be that many yet. Developers
> > >>don't
> > >> seem to be interested in those platform though and I think the focus
> > >>should
> > >> be on BB10.
> > >
> > >
> > >It would probably be more accurate to say "BlackBerry Java" which
> includes
> > >BB 4.6/5/6/7 - yep, we "support" all the way back 4.6 although no one
> > >tests
> > >that far back anymore.
> > >
> > >I've heard BlackBerry voice the opinion that they would like to see
> Apache
> > >Cordova focus solely on BlackBerry 10. However, PhoneGap/Build has seen
> a
> > >large demand for BlackBerry 5 and 6.
> > >
> > >+1 Bada
> > >
> > >+1 webOS - we may want to bring this out of the Attic in the future
> > >
> > >+1 QR - we may want to bring it this out of the Attic when gearing up
> for
> > >Ubuntu Phone
> > >
> > >+0 BB - I want to talk with the our PhoneGap/Build team to better
> > >understand their stance. I'd also like Ken or Jeff from BlackBerry to
> > >chime
> > >in with their opinion.
> > >
> > >On Sun, Mar 17, 2013 at 10:11 AM, Anis KADRI 
> > wrote:
> > >
> > >> +1 to kill those platforms and archive them in the attic :-D
> > >>
> > >> If WebOS, Qt become relevant again we can revive them from the attic.
> > >>
> > >>
> > >> On Sun, Mar 17, 2013 at 10:09 AM, Anis KADRI 
> > >>wrote:
> > >>
> > >> > According to [1]:
> > >> >
> > >> > "Projects whose PMC are unable to muster 3 votes for a release, who
> > >>have
> > >> > no active committers or are unable to fulfill their reporting duties
> > >>to
> > >> the
> > >> > board are all good candidates for the Attic."
> > >> >
> > >> > I believe those projects satisfy the "no active committers"
> argument.
> > >> >
> > >> > I don't see any active committers for Bada, Qt or WebOS.
> > >> >
> > >> > Markus Leutwyler is the only WebOS committer and is no longer
> > >>employed by
> > >> > the company that is in charge of it and I am not sure if he's still
> > >> > interested in maintaining it. There are still devices out there I am
> > >>sure
> > >> > but no new devices are getting shipped.
> > >> >
> > >> > Bada is officially dead [2] but they still released an SDK a couple
> of
> > >> > weeks ago [3] O_O! They still owned #4 spot in Q3 2012 ahead of
> > >>Windows
> > >> > Phone [4]
> > >> >
> > >> > As far as bb 6 and 7, I am sure the majority of devices out there
> are
> > >>BB
> > >> 6
> > >> > and 7. BB10 just came out so there can't be that many yet.
> Developers
> > >> don't
> > >> > seem to be interested in those platform though and I think the focus
> > >> should
> > >> > be on BB10.
> > >> >
> > >> > [1] http://attic.apache.org/
> > >> > [2]
> > >> >
> > >>
> > >>
> >
> http://www.fiercemobilecontent.com/story/samsun

RE: Decreasing the Deprecation Time

[Ken Wallis]

We will definitely care as well as we move directly on top of Cordova.  Cordova 
is being adopted more and more as a platform that others will build on.  A 
certain level of predictability and stability in a platform is certainly 
appreciated at least. ;)  

We will be heavily invested in the plug-in approach here at BlackBerry so that 
is of special concern if it is unstable. 


--

Ken Wallis

Product Manager – WebWorks

BlackBerry

289-261-4369


From: Marcel Kinard [cmarc...@gmail.com]
Sent: Friday, March 15, 2013 9:24 AM
To: dev@cordova.apache.org
Subject: Re: Decreasing the Deprecation Time

On Mar 14, 2013, at 11:02 PM, Michael Brooks  wrote:

> +1 for switching the deprecation window from time to release. Michal summed
> it up perfectly.

Agreed.

>
> It's worth reflecting on Tommy and Simon's input. The deprecation window is
> there to give users adequate warning that breakage is impending. However,
> it's just make-work for us, if our user's don't care or take action.

I care. Or in other words, the users of my product (which embeds Cordova) care. 
I get yelled at by my users when their app breaks when doing an in-place 
upgrade from version n-3 to n of Cordova.

-- Marcel

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Review of Core Platforms

[Ken Wallis]

Sounds like a plan.  I'll do some digging on what plans we will have on 
publishing market numbers, publically or otherwise. ;)

Thanks.
--

Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369


From: Filip Maj [f...@adobe.com]
Sent: Thursday, January 03, 2013 5:36 PM
To: dev@cordova.apache.org
Subject: Re: Review of Core Platforms

Certainly, if RIM can provide some % numbers of people using each OS,
that'd be helpful! Kind of like the Android OS pie chart breakdown of
users across different OS versions.

In the past, at some point we decided to stop supporting BB OS 5 and 4.6,
and removed those Cordova implementations. Just wanted to raise the idea
of doing something similar for OS 7 and PlayBook once those two platforms
get to the same level of usage.

On 1/3/13 2:21 PM, "Ken Wallis"  wrote:

>What does "schedule for removal mean"?  Perhaps we can tie removal to
>some specific metric that we might be able to assist with?  BB7 will
>remain a fairly large base of devices for a while, particularly in
>emerging markets and enterprise, where I think we will continue to see a
>large focus on web-based mobile applications.
>
>While I wholeheartedly support BlackBerry 10 as the primary platform for
>new development, I would like to see support for BB7 continue while it
>remains a large customer base.
>
>Thoughts?
>
>Thanks!
>
>--
>
>Ken Wallis
>
>Product Manager ­ BlackBerry WebWorks
>
>Research In Motion
>
>(905) 629-4746 x14369
>
>
>From: Filip Maj [f...@adobe.com]
>Sent: Thursday, January 03, 2013 4:44 PM
>To: dev@cordova.apache.org
>Subject: Review of Core Platforms
>
>Our CorePlatforms wiki article [1] has this:
>
>
>
>Core: These are the main platforms supported by the Apache Cordova
>project.
>
>* iOS
>* Android
>* BlackBerry
>* Windows Phone
>* Bada
>
>Sunset: These are platforms considered to be on their way out of general
>consumer availability. We offer code, but not distribution of these
>platforms.
>
>* Symbian
>* webOS
>
>Sunrise: These are new platforms coming to Apache Cordova with some
>development under way.
>
>* Tizen
>* Qt
>
>Horizon: These are platforms that we hope to see supported by Apache
>Cordova in the future!
>
>* B2G
>
>
>
>
>Some propositions + questions, all up for debate of course:
>
>- I'm not sure about Bada. Last I checked Bada's passing % of mobile-spec
>is fairly weak (some features are just not doable; correct me if I'm
>wrong). I would like to propose that a platform is eligible for "Core" if
>they have >90% passing rate on mobile-spec. I would vote to move it into a
>new "Marginal" category, along with, say, cordova-mac or cordova-qt. Also,
>Bada-wac, how does this fit in?
>- Where does the ubuntu phone fit into this?
>- I would suggest we schedule removal of the BlackBerry 7 (java) and
>Playbook (Air) implementations, and have our BlackBerry implementation be
>BB10 only moving forward.
>- The "Windows Phone" category above covers both 7 and 8? What about
>Windows 8?
>
>[1] http://wiki.apache.org/cordova/PlatformSupport
>
>
>-
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Review of Core Platforms

[Ken Wallis]

What does "schedule for removal mean"?  Perhaps we can tie removal to some 
specific metric that we might be able to assist with?  BB7 will remain a fairly 
large base of devices for a while, particularly in emerging markets and 
enterprise, where I think we will continue to see a large focus on web-based 
mobile applications.

While I wholeheartedly support BlackBerry 10 as the primary platform for new 
development, I would like to see support for BB7 continue while it remains a 
large customer base.

Thoughts?

Thanks!

--

Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369


From: Filip Maj [f...@adobe.com]
Sent: Thursday, January 03, 2013 4:44 PM
To: dev@cordova.apache.org
Subject: Review of Core Platforms

Our CorePlatforms wiki article [1] has this:



Core: These are the main platforms supported by the Apache Cordova project.

* iOS
* Android
* BlackBerry
* Windows Phone
* Bada

Sunset: These are platforms considered to be on their way out of general
consumer availability. We offer code, but not distribution of these
platforms.

* Symbian
* webOS

Sunrise: These are new platforms coming to Apache Cordova with some
development under way.

* Tizen
* Qt

Horizon: These are platforms that we hope to see supported by Apache
Cordova in the future!

* B2G




Some propositions + questions, all up for debate of course:

- I'm not sure about Bada. Last I checked Bada's passing % of mobile-spec
is fairly weak (some features are just not doable; correct me if I'm
wrong). I would like to propose that a platform is eligible for "Core" if
they have >90% passing rate on mobile-spec. I would vote to move it into a
new "Marginal" category, along with, say, cordova-mac or cordova-qt. Also,
Bada-wac, how does this fit in?
- Where does the ubuntu phone fit into this?
- I would suggest we schedule removal of the BlackBerry 7 (java) and
Playbook (Air) implementations, and have our BlackBerry implementation be
BB10 only moving forward.
- The "Windows Phone" category above covers both 7 and 8? What about
Windows 8?

[1] http://wiki.apache.org/cordova/PlatformSupport


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: Correct spelling for Blackberry?

[Ken Wallis]

Confirmed, 'BlackBerry'
--

Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369


From: Filip Maj [f...@adobe.com]
Sent: Wednesday, January 02, 2013 2:21 PM
To: dev@cordova.apache.org
Subject: Re: Correct spelling for Blackberry?

I believe it is 'BlackBerry' (�)

On 1/2/13 11:17 AM, "Becky Gibson"  wrote:

>Note that this commit,
>https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803
>c3f161830656,
> to cordova-docs breaks the link to the blackberry file on the Getting
>Started page because it changes the case of the second "b" in BlackBerry.
>
>I didn't fix it because I'm not sure what the correct spelling is.
>
>-becky


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

RE: (CB-1823) BlackBerry updates to the docs

[Ken Wallis]

While we would certainly love to see every BlackBerry user upgrade to 
BlackBerry 10 in the first two weeks, it seems like there will be a definite 
transition period.  I would think we will still see significant subscriber 
numbers on BBOS devices for a while.  I would think you will continue to see 
demand for BBOS builds.
--

Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369


From: Filip Maj [f...@adobe.com]
Sent: Wednesday, November 07, 2012 2:50 PM
To: dev@cordova.apache.org
Subject: (CB-1823) BlackBerry updates to the docs

I am starting to lean towards this person's opinion. Combining all the
BlackBerry platforms into one is starting to become heavy.

Clearly RIM is not looking to support BB 5, 6 and 7 moving forward.
Everything coming from RIM is 100% focused on BB 10.

At what point should we consider sunsetting support for the older BB OS
revisions? We are already talking about removing iOS 4.3 support; why not
open dialogue for doing something similar on BB?

On 11/7/12 11:18 AM, "Chad Tetreault (JIRA)"  wrote:

>Chad Tetreault created CB-1823:
>--
>
> Summary: BlackBerry updates to the docs
> Key: CB-1823
> URL: https://issues.apache.org/jira/browse/CB-1823
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: Docs
>Affects Versions: 2.3.0
>Reporter: Chad Tetreault
>Assignee: Michael Brooks
>
>
>** Is there a better way to split up BBOS, PlayBook, and BlackBerry 10
>(QNX) into seperate sections so that developers can easily see the
>information specific to the platform they're targetting?
>
>** Could add add some screenshots for BlackBerry 10? Similar to how the
>iOS guide looks.  I can provide them if needed.
>
>
>
>Section: "Getting Started with BlackBerry"
>
>Replace: WebWorks applications can ONLY be deployed to BlackBerry devices
>running OS 5.0 and higher or the BlackBerry PlayBook operating system.
>
>With: WebWorks applications can ONLY be deployed to the following
>BlackBerry platforms:
>  * BlackBerry OS 5.0 and higher
>  * BlackBerry PlayBook
>  * BlackBerry 10 (QNX)
>
>
>
>2. "Install SDK + Cordova"
>
>Replace: - Download and install one or more of the WebWorks SDKs. Keep
>note of the install directory.
>  * Smartphone Development: BlackBerry WebWorks Smartphone SDK
>  * PlayBook Development: BlackBerry WebWorks Tablet OS SDK
>
>With: Download and install the appropriate WebWorks SDKs for your
>development. BlackBerry 10, BlackBerry PlayBook, and BlackBerry
>Smartphone WebWorks SDKs can be downloaded from the following location:
>https://developer.blackberry.com/html5/download/
>
>*Make note of the installation directory.
>
>
>
>3. "Setup New Project"
>
>Replace: Open up the project.properties file with your favorite editor
>and edit the entries for blackberry.bbwp.dir= and/or playbook.bbwp.dir=.
>Set the value(s) to the directory containing the bbwp binary in the
>WebWorks SDK(s) installed earlier.
>
>With: Open up the project.properties file with your favorite editor and
>edit the entries for the WebWorks SDKs you are using:
>  * blackberry.bbwp.dir=
>  * playbook.bbwp.dir=
>  * qnx.bbwp.dir=
>
>  Set the value(s) to the root directories of the corresponding WebWorks
>SDK(s) you have installed. Example: C:\Program Files (x86)\Research In
>Motion\BlackBerry 10 WebWorks SDK 1.0.2.9
>
>
>
>4. "Hello World"
>
>Replace: Replace target with either blackberry or playbook.
>
>Issue: Replace target with blackberry, playbook, or qnx to build for the
>corresponding platform.
>
>**This appears to be not true. The sample application just displays a
>landing page with no additional functionality. (Get Screenshot) Should
>have a fully functional app.  I've been creating a Kitchen Sink app for
>BB10 which tests all the API's, perhaps we could include this, or link to
>it when it's complete?
>
>
>
>5A "Deploy to Simulator"
>
>Replace: PlayBook simulators require VMWare Player
>
>With: PlayBook and BlackBerry 10 simulators require VMWare Player
>
>**The qnx.sim.ip and qnx.sim.password values aren't mentioned.
>**While in your project directory...
>**There is no mention of qnx anywhere.
>
>Replace: The application will be installed in the All Applications
>section in the simulator.
>
>With: The application will be installed to the homescreen of the
>simulator.
>
>
>
>5B "Deploy to Device (Windows and Mac)"
>
>**There is no 'Setup BlackBer

RE: plan for handling updated device OS versions?

[Ken Wallis]

Unfortunately it is a fact of life that those darn manufacturers do like their 
secrets to an extent. ;)  It seems that your current model of frequent releases 
might be the best approach to deal with the issues, especially because you are 
a customer of many different SDKs, all with different release plans, with 
varying levels of transparency.

I try to keep this up to date as much as I can, but it is not always possible 
to put everything we are working on in there:

https://developer.blackberry.com/html5/download/roadmap/

Look for an update to this sometime later this week... ;)

--

Ken Wallis

Product Manager – BlackBerry WebWorks

Research In Motion

(905) 629-4746 x14369


From: brian.ler...@gmail.com [brian.ler...@gmail.com] on behalf of Brian LeRoux 
[b...@brian.io]
Sent: Wednesday, November 07, 2012 10:47 AM
To: dev@cordova.apache.org
Subject: Re: plan for handling updated device OS versions?

I'd love it if we could sync w/ the manufacturers and os vendors but the
reality here is we're a customer of their SDKs just like everyone else. As
Shaz mentions, we had no idea the new iPhone would change dimensions so
even if we did have a policy we'd be lying.

As Fil says, we should align our point releases to fall just after an
expected release. Again, this is tricky, b/c we never *really* know when
something will ship or if something is just being announced for a future
date.

Having a monthly release cadence seems to be working well enough in any
case. One thing is for sure, we want to continue to have a decoupled
relationship between our development activity and vendor marketing
department activities!


On Tue, Nov 6, 2012 at 12:26 PM, Shazron  wrote:

> We couldn't plan for the iPhone 5 new dimensions / splashscreen that
> enabled tall mode. Ideally we should release _after_ the new iOS/device
> comes out to iron out the kinks.
>
>
> On Tue, Nov 6, 2012 at 10:21 AM, Filip Maj  wrote:
>
> > Thanks for bringing this up.
> >
> > Last time we released 2.1 right _before_ iOS 6 came out (I believe) and
> it
> > became obvious that we should pay more attention to manufacturer release
> > schedules and plan for point releases to be in sync with those.
> >
> > In general our target has been Cordova support is ready to roll by the
> > time the first real device running mobile OS XYZ version 1.2.3 lands in
> > consumer hands.
> >
> > Moving forward I think option #2 you point out below should be the way to
> > go (although we don't necessarily have access to beta programs with all
> > vendors *cough* Apple *cough*). We will rely on Cordova's committers
> > (especially the committers more in charge of owning one particular
> > platform) to mention on the mailing list any soon-to-be-released OS
> > revisions for their platform and help us schedule point releases
> > accordingly. For example the 2.3 planning thread that is floating around
> > right now is a good start. We should be doing these sorts of threads
> after
> > every release IMO.
> >
> > On 11/5/12 1:15 PM, "Marcel Kinard"  wrote:
> >
> > >I'm seeing rumors on the web that iOS 6.1 is in the works from Apple and
> > >there is a beta that recently opened. Is there any sort of target for
> > >handling new device OS versions in Cordova? For example:
> > >
> > >- Cordova should support a new device OS in the next Cordova version 4-6
> > >weeks after the OS becomes generally available
> > >or
> > >- through the participation of betas with the device vendor, and careful
> > >release scheduling, Cordova should support a new device OS on day 1 that
> > >a new OS becomes generally available
> > >or
> > >- (something else entirely, since these are just examples)
> > >
> > >The goal here would be to:
> > >- provide some general direction to consumers and set realistic
> > >expectations.
> > >- provide specific direction to the Cordova development community, and
> > >give us a target to shoot for.
> > >- be consistent in our approach across all the OS vendors (assuming that
> > >is desired).
> > >
> > >Has there been previous discussion on this topic? If not, what are your
> > >ideas on this?
> > >
> > >-- Marcel Kinard
> >
> >
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Re: Whitelist defaults

[Ken Wallis]

Not sure why the BlackBerry version white lists everything. We don't do that in 
WebWorks ;)



From: Steven Gill
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Re: Whitelist defaults
2012-11-01 10:30:42 PM



+1 to point it out in the getting started guides.
On Nov 1, 2012 6:35 PM, "Marcel Kinard" wrote:

> Also sounds like a good step/topic in the "getting started" guides.
>
> -- Marcel Kinard
>
> On 11/1/2012 8:36 PM, Dave Johnson wrote:
>
>> Yup agree it should whitelist nothing but it also needs to be very clear
>> in
>> the log when we block a request that it's due to the whitelist.
>>
>> On Thursday, November 1, 2012, Shazron wrote:
>>
>> I concur with Kevin. It won't be much of a whitelist if no one uses it
>>> -- I
>>> would argue that if you set it to "*" by default, no dev will (usually)
>>> change that, especially if they don't know there is a whitelist in the
>>> first place.
>>>
>>>
>>> On Thu, Nov 1, 2012 at 4:48 PM, Kevin Hawkins <
>>> kevin.hawkins.cordova@gmail.**com > wrote:
>>>
>>> From a security perspective, I'm partial to the iOS (nothing) default,
 recognizing of course that there are certain usability drawbacks to that
 approach.

 On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj >

>>> wrote:
>>>
 Quick q: how come Android + BB's whitelists by default whitelist
> everything (*), but iOS does the opposite (whitelist nothing)?
>
> I'd like to see this unified across all platforms we support.
>
>
>
>

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.