Shift in architecture: from configuration-driven design to a plugin-based architecture

[im7mortal]

I know this sounds LOUD.

First of all, we need injection points, why not allow users to use the Brotli algorithm in their pipeline? A user could write a compressor and decompressor and use them in their closed environment, or even open-source these plugins as a separate library.

Second, if we have this extensibility, why not move all legacy and unpopular implementations into plugins as well? If you need ZipCrypto, inject it as a plugin. If you need legacy-zip, inject it as a plugin.

We would still have zero-cost+optimized main pipelines: aes -> (zstd, deflate, ...) -> crc. If a user wants to change it, they inject a plugin.

This would allow us to clean the library from many flags and options. Smaller error surface, easier reviews, and less load on maintainers.

Related to this PR

Partly related to #204.

[im7mortal]

Just want to keep this table somewhere showing that the Tokio runtime has poor performance for active filesystem reads. Tokio uses readiness-based I/O and offloads file operations to a blocking thread pool, which can scale poorly for heavy disk workloads. Systems like Apache Iggy moved to a thread-per-core architecture with io_uring, allowing truly async disk I/O without a large blocking pool and improving scalability for storage workloads.

https://iggy.apache.org/blogs/2026/02/27/thread-per-core-io_uring/

It supports the idea that libraries shouldn’t rely on a single runtime but remain flexible.

[im7mortal]

Just a quote I want to save

Performance of dyn is not about the trait itself — it’s about where it sits in the call graph