Hi, On Tue, Feb 18, 2014 at 2:25 AM, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > If we can have a way to create JCR Binary implementations which > enables DataStore/BlobStore to efficiently transfer content then that > would help.
ValueFactory.createBinary(InputStream stream) The problem here, as far as I can see, is not within the JCR implementation, but rather in the extra on-disk copy that FileUpload does within Sling. I would suggest using the streaming API mentioned by Ian. > For example for File based DS the Binary created can keep a reference > to the source File object and that Binary is used in JCR API. That's already too late in the process. The temporary file should never get created in the first place. > Another example is S3DataStore - In some cases the file has already > been transferred to S3 using other options. And the user wants to > transfer the S3 file from its bucket to our bucket. So a Binary > implementation which can just wrap the S3 url would enable the > S3DataStore to transfer the content without streaming all content > again [4] Good point. That use case would probably be best handled with a specific InputStream subclass like suggested by Felix for files. > Any thoughts on the best way to enable users of Oak to create Binaries > via other means (compared to current mode which only enables via > InputStream) and enable the DataStores to make use of such binaries? The functionality in JCR-3534 and OAK-834 is somewhat related to this. BR, Jukka Zitting
