On Tue, Feb 18, 2014 at 2:32 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote:
> Good point. That use case would probably be best handled with a
> specific InputStream subclass like suggested by Felix for files.
That mode is fine for case like FileInputStream but not for case like
S3 where underlying data is just a url and DataStore needs to make use
of that. Instead what I was referring to is the ability to pass custom
Binary implementations
- FileBinary implements javx.jcr.Binary -
- File object
- boolean flag indicating that ownership of file. If true it
indicates that client is transferring the ownership of the file to
Oak. In such a case the Oak DataStore can simply move the file
instance to its storage area
- S3Binary implements javx.jcr.Binary
- Signed S3 url which can be used by S3DataStore to perform Copy operation
This binary is then passed to JCR API and then DataStore makes use of
that and chooses an efficient path depending on the type of Binary
Couple of points to note
- Such an API would introduce a strong coupling with underlying DataStore
- But such an API would then be targeted for a very specific usecase
where the code needs to import high amount of binary data and it is
written keeping in mind the underlying DataStore being used such that
it can use the most optimized way
Chetan Mehrotra
