You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by Apache Wiki <wi...@apache.org> on 2016/11/10 06:44:01 UTC

[Jackrabbit Wiki] Update of "JCR Binary Usecase" by ChetanMehrotra

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "JCR Binary Usecase" page has been changed by ChetanMehrotra:
https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase?action=diff&rev1=17&rev2=18

Comment:
Added 2 more usecases

  
  <<BR>>
  
+ === UC13 - adopt-a-binary ===
+ 
+ Mentioned by Bertrand on [[https://lists.apache.org/thread.html/cac83071a7c547581bbf2f2ae2c603742fb2f582b6b9371ac4b33ce8@%3Coak-dev.jackrabbit.apache.org%3E|oak-dev]]. Idea here is that files already exist somewhere and are hence not "managed" by Oak. The binary content just needs to be made accessible via JCR Binary API. Possibly can be implemented if we have hierarchical BlobStore support where one of them enables resolving "external" blobIds like this
+ 
+ === UC14 - Hierarchical BlobStore === 
+ 
+ Idea here is to have blobs stored in different BlobStores depending on type/usage/path. But read happens via same Binary API. Something like this existed in JR2 [[https://jackrabbit.apache.org/api/2.8/org/apache/jackrabbit/core/data/MultiDataStore.html|MultiDataStore]]. Also see [[https://wiki.apache.org/jackrabbit/DataStore#Future_Ideas|JR2 Wiki]]
+ 
  == Solution Proposals ==
  
  === UC1 - processing a binary in JCR with a native library that only has access to the file system ===