[
https://issues.apache.org/jira/browse/OAK-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570592#comment-16570592
]
Alexander Klimetschek commented on OAK-7569:
--------------------------------------------
Option 1 also has 3 different levels if you look at it in detail. From less
complete (a) to full complete (c):
* *a)* Fix just the immediate case in oak-jcr and oak-core as done by Matt in
[this
PR|https://github.com/mattvryan/jackrabbit-oak/commit/e022f846c0ff113c95910d26584568004beacb66]
(linked in my long comment above already)
** Addresses the normal {{getProperty().getBinary()}} and
{{getProperty().getValue().getBinary()}} usages plus multi-value binary
properties.
** I would do the changes slightly differently and just replace all static
method usage outside ValueFactoryImpl, where possible.
** Con: Leaves open {{ValueFactoryImpl.createValue()}} static method usage in
12 files (3 of which are in tests), with unknown impact.
* *b)* Same as a) but also change the createValue() usage in all code paths
that don't start with a NamePathMapper.DEFAULT and don't have access to a
SessionContext currently
** No exact numbers, but NamePathMapper is used in 104 files, and 62 use
{{NamePathMapper.DEFAULT}}.
** A trick and arguable a hack for this case could be to repurpose
{{NamePathMapper}} and add a new interface method {{getInternalValueFactory()}}
to it, which would return {{ValueFactoryImpl}} (or a new internal interface).
In some / most cases the {{NamePathMapper}} is actually the {{SessionContext}},
and this would be simple to do. The API semantics of {{NamePathMapper}} would
be a bit confusing, but at least it would prevent one from changing all the
methods and classes that pass around {{NamePathMapper}} to pass around
something else.
** Con: This leaves open places that end up using {{NamePathMapper.DEFAULT}}.
* *c)* Rigorously ensure everyone using a {{ValueFactoryImpl}} static method
must use an instance, and must have access to the current {{SessionContext}} or
{{SessionImpl}}, and remove use of {{NamePathMapper.DEFAULT}}
** Would surely be a useful improvement.
** Con: Seems like a massive Oak change as mentioned above.
Note that places (at runtime, not tests) that use {{NamePathMapper.DEFAULT}}
today would have at least the limitation that when a NAME or PATH property is
used, and the session has local namespaces, that these aren't respected,
because the default impl has no access to them.
> Direct Binary Access
> --------------------
>
> Key: OAK-7569
> URL: https://issues.apache.org/jira/browse/OAK-7569
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: api, blob-cloud, blob-cloud-azure, blob-plugins
> Reporter: Matt Ryan
> Assignee: Matt Ryan
> Priority: Major
> Attachments: OAK-7569-api-javadoc-improvements.patch
>
>
> Provide a direct binary access feature to Oak which allows an authenticated
> client to create or download blobs directly to/from the blob store, assuming
> the authenticated user has appropriate permission to do so. The primary value
> of this feature is that the I/O of transferring large binary files to or from
> the blob store can be offloaded entirely from Oak and performed directly
> between a client application and the blob store.
> This feature is described in more detail [on the Oak
> wiki|https://wiki.apache.org/jackrabbit/Direct%20Binary%20Access].
> This feature is similar in functionality to OAK-6575. It adds the capability
> to also upload directly to storage via preauthorized URLs in addition to
> downloading directly from storage via preauthorized URLs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
