I would prefer a 2 phase implementation here A - CompositeBlobStore ---------------------------------
Have support for multiple BlobStores plugged within an Oak setup and provide an API for layer above to select which BlobStore should be used. This forms the lower most layer in stack. Such a feature should support 1. Selecting which store a binary should be written to 2. How binary gets read 3. Support Blob GC B - BinaryStorage Support ------------------------------------ Once we have A implemented then layer above can implement some logic to manage where binaries are stored without requiring major changes in core. For example Oak can extend the current extension point in BlobStatsCollector to allow plugging in custom stats collector. This can be then used by application to build logic to move content based on various heuristics 1. Path Based 2. Access Based Application can then use std api to "copy/move" binary from one store to another. We can also provide some out of box implementation but key thing here is that it should be built on top of Oak Core and hence plug-gable. Given that we have been discussing enhancements in Binary area for long time now [1] it would be better to get #A implemented now with an eye for requirements of #B. So that we make some progress here Chetan Mehrotra [1] https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase
