Hi Chetan, On Wed, Jun 1, 2016 at 9:30 AM, Chetan Mehrotra <[email protected]> wrote: > ...To move forward on that I have tried to collect the various usecases at [2] > which I have seen in the past....
I've thought about adding an "adopt-a-binary" feature to Sling recently, to allow it to serve existing (disk or cloud) binaries along with those stored in Oak. I think this might help for your use cases. I'm not sure about implementing it at the Sling level or in a custom BlobStore so far, but that's not important at this point. Here's how I envision this: 1. Client prepares a set of binaries and metadata on disk or on cloud storage. This happens without interacting with Sling, to make it easier to farm out the costly binary preparation / metadata extraction etc. 2. Client POSTs those binaries and their metadata to Sling, but instead of including the actual binaries it uploads small references in a specific binary format that's conceptually like SLINGREF:mystore:myfile.mp4: a constant prefix + binary URI. 4. When serving such a binary, Sling recognizes the SLINGREF: prefix (which needs to be made robust/unique) and dereferences it to get an InputStream Of course this means fully delegating the management of binaries to external tools, though they can be replaced transparently with actual non-adopted ones. Also, if fine-grained access control is needed it needs to be implemented by the URI resolvers that provide the actual binaries. But in some cases I think using Sling/Oak as "just" a metadata decorator for existing binaries might make a lot of sense. Although this is a Sling idea and only in the back of my mind so far, I wanted to mention it here as there are parallels with your use cases. -Bertrand > [2] https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase
