Hello,
as I've announced in advance, I'm offering a small code refactoring.
While the rdedup_lib internals are well-ready for a new backend being implemented, currently one has to implement it directly to the rdedup_lib which is not very handy. This PR changes this - it only makes some necessary structs and traits visible so anyone can implement a new backend into his own code and use redup_lib as it is, only as a dependency.
An example how the usage will look like afterward can be seen here: RemoteBackend and its usage (please mind/excuse its PoC status).
The API is exposed via some artificial modules. The reason is that exposing them with their real nestings would IMHO look confusing to a newcomer and, on the other hand, refactoring it to follow these artificial modules structure would be much bigger cut to the library - maybe worth it though. It's up to you, of course.
Hello, as I've announced in advance, I'm offering a small code refactoring.
While the
rdedup_libinternals are well-ready for a new backend being implemented, currently one has to implement it directly to therdedup_libwhich is not very handy. This PR changes this - it only makes some necessary structs and traits visible so anyone can implement a new backend into his own code and useredup_libas it is, only as a dependency.An example how the usage will look like afterward can be seen here:
RemoteBackendand its usage (please mind/excuse its PoC status).The API is exposed via some artificial modules. The reason is that exposing them with their real nestings would IMHO look confusing to a newcomer and, on the other hand, refactoring it to follow these artificial modules structure would be much bigger cut to the library - maybe worth it though. It's up to you, of course.
Thanks for your great work :handshake: