Alexander Klimetschek commented on OAK-7570:

.bq That's the beauty of it. The oak-jcr layer doesn't need to know where it 
comes from. Loose coupling gives you the freedom to combine components in 
different ways.

In our original approach oak-jcr also doesn't know where it comes from - it 
just sees the extension interface on the Oak API (Root), which already covers 

With the whiteboard, how do you know which HttpBlobProvider to use if there are 
multiple DS (looking at CompositeDataStore cases)?

It really is an extension of _the_ Blob/DataStore. It is not supposed to be 
some separate component that someone else could provide...

> [DirectBinaryAccess][DISCUSS] How to access HttpBlobProvider from oak-jcr
> -------------------------------------------------------------------------
>                 Key: OAK-7570
>                 URL: https://issues.apache.org/jira/browse/OAK-7570
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: jcr
>            Reporter: Matt Ryan
>            Assignee: Matt Ryan
>            Priority: Major
> Open discussion related to OAK-7569:
> The [original pull request|https://github.com/apache/jackrabbit-oak/pull/88] 
> proposes changes to oak-api, oak-segment-tar, oak-store-document, oak-core, 
> and oak-jcr as well as oak-blob-plugins, oak-blob-cloud, and oak-blob-azure.  
> Would it be possible / better to keep the changes local to the oak-blob-* 
> bundles and avoid making changes throughout the stack?

This message was sent by Atlassian JIRA

Reply via email to