The patch and pull request are ready since one week ago. The patch handles
the 304 status code for android adding a new error status code, I've also
updated the documentation and the mobile spec tests. Shall I do something
more? TIA.
I've explained my use case in the issue CB-6928 but as summary I'm creating
a simple rsync to keep the data in the device up to date.
2014-06-18 4:08 GMT+02:00 Ian Clelland iclell...@chromium.org:
On Tue, Jun 17, 2014 at 9:34 PM, Andrew Grieve agri...@chromium.org
wrote:
If it's cached...
Okay, think I got it and sounds good to me.
On Wed, Jun 18, 2014 at 3:48 AM, Javier Puerto jpue...@gmail.com wrote:
I've explained my use case in the issue CB-6928 but as summary I'm creating
a simple rsync to keep the data in the device up to date.
2014-06-18 4:08 GMT+02:00 Ian Clelland
2014-06-16 17:01 GMT+02:00 Andrew Grieve agri...@chromium.org:
I think this behaviour has been around for a while, and makes sense in the
majority of cases.
Yep, I did a git blame and this fragment of code was there from the
beginning.
Best practice is to download to a temporary location,
How about adding a second parameter to the callback? Android and iOS
bridges both support this natively, and you can simulate it on other
platforms by manually unpacking the parameters in your own callback.
On Tue, Jun 17, 2014 at 4:18 AM, Javier Puerto jpue...@gmail.com wrote:
2014-06-16
I think it's better to use the error callback because for cached resources
doesn't makes sense to use the Entry as parameter as the target will not
exists..There's no error but the file transfer was unable to download
anything due to the 304 response so IMO the error callback could do the job.
If it's cached... won't it exist?
On Tue, Jun 17, 2014 at 11:56 AM, Javier Puerto jpue...@gmail.com wrote:
I think it's better to use the error callback because for cached resources
doesn't makes sense to use the Entry as parameter as the target will not
exists..There's no error but the file
On Tue, Jun 17, 2014 at 9:34 PM, Andrew Grieve agri...@chromium.org wrote:
If it's cached... won't it exist?
Exactly this. A 304 request should only be received in response to a
conditional GET request. There's generally no reason to send a conditional
GET unless you already have a cached copy
Hi Cordova developers,
I'm creating a system to download/update several resources from a server to
the device and I've observe a behaviour that breaks my use case.
After fix the issue CB-6928, I'm able to download/update all the resources
without problems. My next test was to try to download the
I think this behaviour has been around for a while, and makes sense in the
majority of cases. Best practice is to download to a temporary location,
and then upon success move the file to its final spot.
That said, I think it'd be fine to add an option for not delete on error.
On Mon, Jun 16,
10 matches
Mail list logo
