Open weeeBox opened 3 years ago
hi @weeeBox
I'm confused about the terms (download task, download job & download worker) you use in the design of file downloader library.
Download Task
represents an asynchronous download operationDownload Job
contains Download Request
, Download Task
and stateDownload Worker
is expensive and handles blocking I/OFor me, Download Job
is the same as Download Task
, and also the same as Download Worker
. No need to split it up.
I saw your argument like "There might be an unlimited number of jobs and only a handful of workers (limited by the pool size)."
However, I can say the same like "There might be an unlimited number of requests, but only a handful of active simultaneous download tasks, the remaining tasks are in the waiting queue"
in iOS, I don't see the terms like Job
& Worker
. There is a similar implementation of Download Task
like URLSessionDownloadTask class
in iOS.
- open var currenRequest: URLRequest { get }
- open var state: URLSessionTask.State { get }
- open func resume()
- open func cancel()
- open func suspend()
// for reporting
- open var countOfBytesReceived: Int64 { get }
- open var countOfBytesExpectedToReceive: Int64 { get }
The request
& state
are put in the same class. No Job, no worker. May be, this way is simpler.
About the issue of how to keep track of downloaded files, Apple implements the same as you do. Apple stores the raw files in the cache folder, and meta data of this file (probably like url, path, created_at, total_bytes, ...) in a SQLite database.
I think we are still missing the discussion about caching (in-memory, disk cache) to avoid the unnecessary network calls. Thanks for a great solution for this topic. I love it :)
Thanks, @chipbk10! I'm currently on the road - would take a closer look after Christmas.