Hi
Please review pull following requests:
* CB-4919 - Added docs for Firefox OS
https://github.com/apache/cordova-plugin-camera/pull/7
* CB-3206 - Supported platforms updated
https://github.com/apache/cordova-plugin-vibration/pull/8
* CB-5326 - readded the permission info and updated
Took a look at the patch, looks good. Seems you do some cleanup of plugin
handling at the same time, which is nice, but you may want to consider
splitting into two commits in case we want to revert just the search path
bit.
On Tue, Jan 14, 2014 at 10:29 AM, Michal Mocny mmo...@chromium.org
Actually, looking again, there's a custom API just for SSL certs that
will provide you the cert to check: onReceivedSslError().
On Tue, Jan 14, 2014 at 12:29 AM, Tommy-Carlos Williams
to...@devgeeks.org wrote:
I guess the answer for core would then lie in custom trust managers after all?
Would
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16854/#review31727
---
Ship it!
Ship It!
- Andrew Grieve
On Jan. 14, 2014, 5:34 a.m.,
On Mon, Jan 13, 2014 at 9:16 PM, Andrew Grieve agri...@chromium.org wrote:
I think we need two things for transitioning to different PERSISTENT /
TEMPORARY locations:
1. The ability for the user to retrieve the files at the old location
(so they can be moved to the new location)
2. The
I'd like to do a tools release today or tomorrow. Any reason to postpone?
If I don't hear back, I'll go ahead with it either this eve or tomorrow.
I made some tiny comments. Otherwise, looks good.
We have a Google Hangout coming up and discussing this is on the
agenda. My thinking as of now is that there's a general agreement that
this is a great idea, but that it's not on anyone's roadmap atm.
On Mon, Jan 13, 2014 at 12:48 AM, Hu, Ningxin ningxin...@intel.com wrote:
Hi Folks,
Regarding
Lets let cli search paths land?
On Tue, Jan 14, 2014 at 10:58 AM, Andrew Grieve agri...@chromium.orgwrote:
I'd like to do a tools release today or tomorrow. Any reason to postpone?
If I don't hear back, I'll go ahead with it either this eve or tomorrow.
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16854/#review31728
---
This is now merged. Please close the review. :)
- Andrew Grieve
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16739/#review31729
---
Ship it!
Merged!
- Andrew Grieve
On Jan. 14, 2014, 5:33 a.m.,
And onReceivedSslError would cover the self-signed scenario, but it wouldn't
cover the real pinning scenario with a properly signed cert, because it gets
invoked only on a handshake failure, not a handshake success.
On Jan 14, 2014, at 11:38 AM, Marcel Kinard cmarc...@gmail.com wrote:
I've
I've been thinking about this for a couple of days; it's taken a while to
think everything through so I can respond properly here.
I'm generally +1 on certificate pinning; I think it's one of the best
things to come along to fix some of the biggest problems with SSL/TLS.
(HSTS is the other). I
Sounds like the ouput of this how it works should go in cordova-docs. If it's
not clear to us, then it won't be clear to users. ;-)
On Jan 13, 2014, at 9:36 PM, Andrew Grieve agri...@chromium.org wrote:
On Mon, Jan 13, 2014 at 6:14 PM, Gorkem Ercan gorkem.er...@gmail.com wrote:
On Mon, Jan
Landed :)
On Tue, Jan 14, 2014 at 11:11 AM, Michal Mocny mmo...@chromium.org wrote:
Lets let cli search paths land?
On Tue, Jan 14, 2014 at 10:58 AM, Andrew Grieve agri...@chromium.orgwrote:
I'd like to do a tools release today or tomorrow. Any reason to postpone?
If I don't hear back,
On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve agri...@chromium.orgwrote:
On Tue, Jan 14, 2014 at 10:38 AM, Ian Clelland iclell...@chromium.org
wrote:
On Mon, Jan 13, 2014 at 9:16 PM, Andrew Grieve agri...@chromium.org
wrote:
I think we need two things for transitioning to different
So, to be clear and terse: what are the use cases / why are we adding more
config?
On Tue, Jan 14, 2014 at 10:34 AM, Ian Clelland iclell...@chromium.orgwrote:
On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve agri...@chromium.org
wrote:
On Tue, Jan 14, 2014 at 10:38 AM, Ian Clelland
I'll let Ian answer, but my understanding:
- We are storing some files in the wrong place right now, but we need to
continue storing in the wrong place by default for apps to not break on
upgrade
- We want to store files in a few new places that haven't been supported
until now
- We want to roll
..and we are now discussing how best to balance config flexibility vs
config grok-ability
On Tue, Jan 14, 2014 at 1:48 PM, Michal Mocny mmo...@chromium.org wrote:
I'll let Ian answer, but my understanding:
- We are storing some files in the wrong place right now, but we need to
continue
On Tue, Jan 14, 2014 at 1:44 PM, Brian LeRoux b...@brian.io wrote:
So, to be clear and terse: what are the use cases / why are we adding more
config?
1. NSDocumentsDirectory is a stupid place to put the HTML filesystem on
iOS. NSLibraryDirectory is a more sensible place, and I'd love to
So, for arguments sake, is
1. Storing files in wrong place in 3.3.0 so don't upgrade. Versioning was
one of the wins with moving to plugins.
2. Storing files in new places: config won't help us b/c you still need
code to persist to those new places (for old things that want to use new
things see
Stopping to think about #1 for a bit. I *believe* that there are good and
compelling reasons why versioning doesn't necessarily help as much as it
should, but I'd like to be more certain before continuing.
On Tue, Jan 14, 2014 at 2:14 PM, Brian LeRoux b...@brian.io wrote:
So, for arguments
Wait, users lose data IF they upgrade the plugin. Is that correct?
On Tue, Jan 14, 2014 at 10:53 AM, Ian Clelland iclell...@chromium.orgwrote:
On Tue, Jan 14, 2014 at 1:44 PM, Brian LeRoux b...@brian.io wrote:
So, to be clear and terse: what are the use cases / why are we adding
more
+1 to deprecate. Tested Web GPS on 2.3 (lowest that we have) and it worked
fine.
On Mon, Jan 13, 2014 at 1:54 PM, Joe Bowser bows...@gmail.com wrote:
So, an update on this.
1. Our users don't know how GPS works! I can reproduce Geolocation
errors only by disconnecting my WiFi and by not
Ya I like the single preference. So, I think we agree that new plugin
locations are opt in via upgrade (regardless of config). We can also see
that plugin persistence locations are also only available by an opt in
upgrade.
I'm thinking that migration *might* be the use case but this is not well
On Tue, Jan 14, 2014 at 2:52 PM, Brian LeRoux b...@brian.io wrote:
Wait, users lose data IF they upgrade the plugin. Is that correct?
*If* we change the default storage location, and *if* a developer upgrades
the file plugin without looking too closely (because, hey, newer is always
better,
Brian,
If you're using DataURL for destinationType in your cameraOptions, it will
crash all day, every day as JavaScript on many mobile devices can't manage an
object as large as a hi-res image as a string.
John M. Wargo
Twitter: @johnwargo
-Original Message-
From: Brian Zitzow
Yeah, only working with self-signed certs is kind of a deal breaker.
Most apps consume an api/server that is also consumed by webapps.
Thanks for still thinking about this...
On 15/01/2014 3:41 am, Marcel Kinard cmarc...@gmail.com wrote:
And onReceivedSslError would cover the self-signed
added to the f2f agenda
On Tue, Jan 14, 2014 at 12:30 PM, Tommy Williams to...@devgeeks.org wrote:
Yeah, only working with self-signed certs is kind of a deal breaker.
Most apps consume an api/server that is also consumed by webapps.
Thanks for still thinking about this...
On 15/01/2014
Ahem, Why not write a plugin?
A 'filemigrator' plugin could blindly copy files from the old location to
the new one, and set some flag for itself that it had done it's work (to
the file system).
If the flag is set, it would do nothing.
filemigrator would have the new version of
Sorry…
I have been trying not to chicken-little this thread, but I just need some
clarification on some things.
My understanding, please correct me if I am wrong:
The “old location on iOS is not the best location for files the dev doesn’t
want exposed, but it *is* where they should be if the
Migration isn't possible by default because the current location for
Android is the root of the SD Card.
The goal here is to put PERSISTENT under Library, but to also make
other interesting places available via other URLs / FileSystem
objects.
So far my fav. is to have the plugin broken by
I agree with the plugin broken by default, and requiring From my
experience, doing anything fancy for users to ease migration rarely does
what is intended - and causes more problems, my 2c
FileMigrator plugin is great, externalizes the problem
On Tue, Jan 14, 2014 at 1:10 PM, Andrew Grieve
It looks like the FFOS stuff has been merged, but it appears to break the
camera plugin. I think a commit has been merged for a second time, and
that may have broken things. I left a comment in the pull
requesthttps://github.com/apache/cordova-plugin-camera/pull/7
.
Herm, can you take a look?
Howdy,
I think there are too many default engines defined.
for instance
engine name=cordova-android version==1.8.0 /
is essentially the same as
engine name=cordova version==1.8.0 platform=android /
Could someone remind the reason for having platform specific default
engine names? If
Oddly, the plugin appears to be fixed now.
On Tue, Jan 14, 2014 at 4:26 PM, Max Woghiren m...@chromium.org wrote:
It looks like the FFOS stuff has been merged, but it appears to break the
camera plugin. I think a commit has been merged for a second time, and
that may have broken things. I
Sadly ya. We could spin up an afternoon (PST) recap?
On Tue, Jan 14, 2014 at 1:32 PM, Tommy-Carlos Williams
to...@devgeeks.orgwrote:
ugh… 4:30-6:30 am ;)
On 14/01/2014, at 6:17 AM, Brian LeRoux b...@brian.io wrote:
I put together a doodle of potential dates/times to have the hangout [1]
MS Open Tech would be hosting this in Seattle/Redmond. Could not edit the wiki
page for some reason.
-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian
LeRoux
Sent: Tuesday, January 14, 2014 1:54 PM
To: dev@cordova.apache.org
Subject: Re:
OK, So it looks like the consensus was src/platform?
Also, are we doing that resource tag, or is it cool if I just leave
this as using the source tag. I'm going to be merging this in the
next two days.
On Tue, Dec 3, 2013 at 6:01 PM, Brian LeRoux b...@brian.io wrote:
src/platform seems
nice little lib that came in handy today: thx guys!
Woohoo!
On Tue, Jan 14, 2014 at 7:33 PM, Brian LeRoux b...@brian.io wrote:
nice little lib that came in handy today: thx guys!
If anyone wants to take ownership of an agenda item, I think that
would help keep things more organized. Maybe put your name next to the
item on the wiki page?
On Tue, Jan 14, 2014 at 5:04 PM, Parashuram Narasimhan (MS OPEN TECH)
panar...@microsoft.com wrote:
MS Open Tech would be hosting this
http://plugins.cordova.io seems borked. It's slow, pages aren't loading,
search is broken.
Does something need to be restarted?
On Thu, Jan 9, 2014 at 4:16 AM, Erik Jan de Wit ede...@redhat.com wrote:
Still something strange going on, there is no way to search!
Cheers,
Erik Jan
I've been noticing the same thing. I will take a look at this tomorrow.
On Tue, Jan 14, 2014 at 6:40 PM, Don Coleman don.cole...@gmail.com wrote:
http://plugins.cordova.io seems borked. It's slow, pages aren't loading,
search is broken.
Does something need to be restarted?
On Thu, Jan 9,
44 matches
Mail list logo
