Hi,
I’ve been looking into this project and I’m interested in how extensible the storage backend model is.
From what I understand, the current implementation is primarily designed around S3-compatible object storage. I’m curious whether it would be considered in scope for this project to support additional transport or storage protocols beyond S3.
For example:
My thinking is that a pluggable backend abstraction could allow multistore to route requests not only to different S3 buckets or regions, but also to different storage protocols entirely, depending on configuration or routing rules.
I realize this could introduce significant architectural complexity, so my main question is:
- Is multi-protocol storage support something that aligns with the long-term goals of this project?
- Or is the design intentionally focused on S3-compatible object storage only?
I’d appreciate any insight into the intended scope or architectural constraints.
Thanks for building and maintaining this project.
Hi,
I’ve been looking into this project and I’m interested in how extensible the storage backend model is.
From what I understand, the current implementation is primarily designed around S3-compatible object storage. I’m curious whether it would be considered in scope for this project to support additional transport or storage protocols beyond S3.
For example:
My thinking is that a pluggable backend abstraction could allow multistore to route requests not only to different S3 buckets or regions, but also to different storage protocols entirely, depending on configuration or routing rules.
I realize this could introduce significant architectural complexity, so my main question is:
I’d appreciate any insight into the intended scope or architectural constraints.
Thanks for building and maintaining this project.