Filedownloader: expose generating id of BaseDownloadTask

[chriswiesner]

i request my download Urls from a Webservice which adds hashcodes as parameters (url availability is timeboxed from server) and additional information to the Url.

therefore if i'm requesting the same file two times, the url is (sightly) different. currently the download id is generated from url and path which prevents me of checking if file the file is already downloading.
so the goal would be to override the Generation of the id (e.g. then strip the hashcodes out of the url to have a "consistent" id for the same file)

[Jacksgong]

Thank you for your prompt. I know what's you mean. In the current version(0.3.3), you can use the alternative way to handle your problem: add params in request-header(BaseDownloadTask#addHeader) instead in Url.

---

For your consideration, I will enhance the FileDownloader to handle bellow two cases:

1. Two(or more than two) different Tasks with the same target path. (The case of writing data to one file simultaneously by several different input streams must not meet expectation)
2. As your case, different Url not means different resources exactly.

[mseroczynski]

I'd also vote for simplest solution - exposing id setting to the developer.

[Jacksgong]

I will consider doing that in the next version - exposing id setting to the developer.

[mseroczynski]

Kindly please respond - is it done? Will it be released in nearest 2 weeks? I'm in the process of choosing new downloader but this is a must-have.

The case is that often url has some generated short-lived authorization token which makes FileDownloader 'think' that it should be downloaded as different file.

[mseroczynski]

Hey, maybe you could find few seconds to respond sometime? I'm counting on it!

[Jacksgong]

Sorry for delay to 1.5.2. I will do this through:

1. consider the FileDownload service may be on the separate process, it will be implemented like cusotmize-component way.
2. old-ids on the database will be migrated each time when the FileDownload service start.
3. on the runtime, I will use the id you provide with no hesitate、no redundant processing for it.

[mseroczynski]

@Jacksgong When are you planning to release 1.5.2? Like in a week/month/year?

[Jacksgong]

@mseroczynski I try to release 1.5.2 in a week.

[Jacksgong]

Change to 1.5.3 because of 1.5.2 has been released now with some urgency fix, which will not affect the processing of this feature.

[Jacksgong]

Now, FileDownloader support customizing the download task identify through FileDownloadHelper.IdGenerator and can be validated like this.

BUT ONE MORE THING

The customized IdGenerator be used on the FileDownloadService and the upper-layer, so as default FileDownloadService is running on the :filedownloader process, and upper-layer is on the user process, in this case, if you want to cache something on the IdGenrator instance, it would be two different caches on two processes.

Tips: if you want the FileDownloadService runs on the upper-layer process too, just config process.non-separate=true on the filedownloader.properties , more detail move to here