jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-7569) Direct Binary Access
Date Mon, 06 Aug 2018 23:23:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570592#comment-16570592
] 

Alexander Klimetschek edited comment on OAK-7569 at 8/6/18 11:22 PM:
---------------------------------------------------------------------

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 branch|https://github.com/mattvryan/jackrabbit-oak/tree/direct-binary-access-v2-with-create-binary-value-fix]
 ** 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
actually use 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}}.
Some might be from different uses of this interface.
 ** 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.


was (Author: alexander.klimetschek):
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
actually use 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}}.
Some might be from different uses of this interface.
 ** 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)

Mime
View raw message