Limiting direct access to the members of Target lead to a lot of discoveries about the organisation of Downloader and zck data and functions, which is why this commit is quite bigger than initially expected. 😬
Some code have been moved from Downloader to Target member functions as they are mainly manipulating the state of Target without much changes to Downloader, which basically is a sign that it's code related to Target.
This is really just side effects of trying to make the Target interface more contained. Because a lot of other code was manipulating it's internals directly, it ended up touching a lot of code.
Where possible I tried to keep the order and meaning of the code when I had to move it around.
More info and discoveries (to help lead the related PRs that will come soon):
There is multiple accidental data structures hidden in Target, most related to different aspects of a download process.
This makes difficult to follow which states Target can take and when (there is also a lot of redundancy in how Target's state is changed).
Target, Downloader and zck data/functions are intertwined in a way that suggests there is a several separation necessary (but I didn't proceed where I didn't need to, for now) - basically this lacks "separation of concerns" and should be improved.
Both Target and zck seems to be internal details of Downloader's mechanisms, which is fine, but it also means we should not expose them as public interfaces (I think, or at least not completely).
Downloader::check_msg seems to have at least 3 transfer error flags that might be contradictory; this makes difficult to understand which flag means what kind of error.
All this will probably participate to complications in evolving libpowerloader, but we are in a good position and time to improve the situation. :)
Looks like the python tests are "blocking" somewhere in test/test_other.py. I'm reviewing to check which code changed order or meaning compared to main branch.
Limiting direct access to the members of
Target
lead to a lot of discoveries about the organisation ofDownloader
andzck
data and functions, which is why this commit is quite bigger than initially expected. 😬 Some code have been moved fromDownloader
toTarget
member functions as they are mainly manipulating the state ofTarget
without much changes toDownloader
, which basically is a sign that it's code related toTarget
.This is really just side effects of trying to make the
Target
interface more contained. Because a lot of other code was manipulating it's internals directly, it ended up touching a lot of code. Where possible I tried to keep the order and meaning of the code when I had to move it around.More info and discoveries (to help lead the related PRs that will come soon):
Target
, most related to different aspects of a download process.Target
can take and when (there is also a lot of redundancy in howTarget
's state is changed).Target
,Downloader
andzck
data/functions are intertwined in a way that suggests there is a several separation necessary (but I didn't proceed where I didn't need to, for now) - basically this lacks "separation of concerns" and should be improved.Target
andzck
seems to be internal details ofDownloader
's mechanisms, which is fine, but it also means we should not expose them as public interfaces (I think, or at least not completely).Downloader::check_msg
seems to have at least 3 transfer error flags that might be contradictory; this makes difficult to understand which flag means what kind of error.All this will probably participate to complications in evolving
libpowerloader
, but we are in a good position and time to improve the situation. :)