Current Planning 2022-07

[Klaim]

I will list here the issues I have noted to work on and discussed with @wolfv and @JohanMabille, priorities are mostly on integration into mamba and correctness. Most of these issues imply reviews, discovery and discussion.

Important for helping with integration in Mamba:

• Review and "close" interfaces (currently most of the data is public): this implies some refactoring and probably adding some interfaces in a way simpler than just adding getter/setters.
• libpowerloader as shared library support: currently missing explicit symbol import/export markers for correct generation of dlls on windows and potentially constraint the ABI surface and binary size of shared libraries on other platforms.
• Improve the object ownership model/architecture: mostly to simplify the internals, helping to make sure it's correct, and make usage simple; implies exploring ways to maybe avoid shared pointers.
• Handle potential duplication of utility functions/types between libmamba and libpowerloader, there are several ways to do this and it's possible it is not worth it for now.
• Review standard filesystem usage of libpowerloader: if issues with unicode are possible, we might need to use Use standard C++ filesystem API only mamba#1665 in libpowerloader too.

Code Quality Improvements:

• Add Address, UB and Thread sanitizers support and use them in the CI: this is typically the kind of project/domain where we have to be the most correct possible.
• Elevate warning levels for all compilers to catch subtle issues and fix them. In particular the ones related to security.
• Improve and add unit tests. While we have some, it's probably not enough.

Note: I named this issue quickly, not sure if that's a good name.

Powerloader integration in mamba: mamba-org/mamba#1503

[Klaim]

Right now I'm looking at the ownership model with Johan (in parallel but we will sync at some point), and the shared library support, as I believe it's mandatory to help with integrating in lilbmamba.

[Klaim]

Shared library support is done: #112

[wolfv]

We use shared_ptr in two places -- for Mirrors and DownloadTargets. I think for Mirror it might be easy enough to get rid of the shared pointer, but not sure about DownloadTargets. At least if we also want to allow users to store them independently.
Anyways, I don't "mind" them so much since it's clearly not performance critical.

[Klaim]

Anyways, I don't "mind" them so much since it's clearly not performance critical.

That point is more about correctness and ease of reasoning (so that correctness can be "read") than performance, which is why "value semantics" is often pushed a lot against any kind of pointer and reference semantics.
I'll try the improvements on that side as soon as I'm done with the closing of interfaces. 👍🏽