cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: File-transfer: delete target file on process error
Date Tue, 17 Jun 2014 14:27:20 GMT
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 <jpuerto@gmail.com> wrote:

> 2014-06-16 17:01 GMT+02:00 Andrew Grieve <agrieve@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,
> > and then upon success move the file to its final spot.
> >
>
> Yes, this is what I will have to do at the end. The thing is that I want to
> avoid a double step process. Anyway I'm still thinking that a hard coded
> and undocumented behaviour is not a good practice neither, mostly because
> there's the tools for the developer to act as he needs with the success or
> error callback. It's about flexibility.
>
>
> >
> > That said, I think it'd be fine to add an option for not delete on error.
> >
>
> It seems like the file transfer download is oriented to use a temporary
> directory so it's fine for me as is (keep it simple). I think that an
> explanation in the plugin documentation should be great so everyone can
> figure how to use the download.
>
> About the issue CB-6928, my patch it's not valid for me as I will use the
> temporary directory now and probably for everyone so I will have to cancel
> the pull request. The problem is still there but I wonder how can we fix it
> if the success callback argument is an "Entry" object, the ideal should be
> to be able to communicate the caching status. I will change the patch to
> use the error callback to communicate the caching status, it's not an error
> but I don't see other way. I will add also the documentation for the new
> caching status code and open a new pull request.
>
>
> >
> >
> > On Mon, Jun 16, 2014 at 5:39 AM, Javier Puerto <javier@apache.org>
> wrote:
> >
> > > 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 resources but
> > > with no server response (stopped). I've found that the plugin is
> deleting
> > > my target file silently because there's was an error.
> > >
> > > I think that the developer should be the responsible to delete or leave
> > the
> > > "corrupted" file because the file-transfer plugin already communicates
> > the
> > > error, I don't think that the hardcoded behaviour is a good solution.
> >  What
> > > do you think?
> > > I can open a new issue and provide the patch and test case (Android
> only)
> > >
> > > Best regards.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message