Closed veloman-yunkan closed 3 months ago
Attention: Patch coverage is 0%
with 15 lines
in your changes are missing coverage. Please review.
Project coverage is 40.93%. Comparing base (
922c138
) to head (3733e50
).
Files | Patch % | Lines |
---|---|---|
src/downloader.cpp | 0.00% | 15 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
It is a technical approval. Maybe we need a extra step of discussion if this is a better solution than #1052 (or not)
@veloman-yunkan Do we agree to merge this solution ?
@veloman-yunkan Do we agree to merge this solution ?
I think that it may be the best way to proceed. Although my intuition tells me that we may eventually run into other (more subtle) issues connected with this approach, I don't see why we should try to absolutely avoid them, since we can easily switch to the dumb solution at any time.
Let's go with this solution then. If we face some bug with this, we will see then what to do.
This PR is an alternative to #1052. Similar to the latter it addresses the user-observable problems behind #1050 without fixing that issue the way it was formulated.
The shared property of #1052 and this PR is that they try to solve the bugs without enhancing the libkiwix API. The difference is that this PR tries to make
Downloader::startDownload()
smarter, whereas #1052 deprived it of the slightest smartness that it tried to exercise.Now having tried both approaches I think that we better follow the dumb path. Although we can close the seemingly small gap in
downloadCanBeReused()
(marked with anXXX
comment) my feeling is that trying to optimize for a theoretical situation that can hardly happen in practice is not justified.