[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13650886#comment-13650886
]
Tommaso Teofili commented on JCR-3534:
--------------------------------------
> Any key generation should come from the repository itself. Currently it's
> mixed - generating is done by the client (needs to know the right format) and
> later reading & validating is done by the repository in createValue(). It
> should all be done by the repository, the client code should not have to know
> the format of the signature. I was thinking that we change the
> JackrabbitValue#getContentIdentity() [0] to return the final secure/signed
> token format. Should be possible to detect old and new IDs IMHO. This
> requires that other code (where?) that uses the content identity can work
> with the new format as well.
generating a BinaryReferenceMessage has to be done with
BinaryReferenceMessage(String contentIdentity, String key, long
referencedBinaryLength) which doesn't require any knowledge of signature /
message format.
I'm -0.5 for changing JackrabbitValue#getContentIdentity(), IMHO that may be
really confusing as it wouldn't expose the content identity anymore but a
message with other semantics.
> - BinaryReferenceMessage should go into jackrabbit-api instead of
> jackrabbit-jcr-commons since it's a specific Jackrabbit API and jcr-commons
> is more about utilities around both JCR API users and JCR implementors, which
> makes it hard to find actual jackrabbit specific features
if you'd say jackrabbit-core then it probably makes more sense, otherwise it
seems to me this is not "that" high level to justify its belonging to
jackrabbit-api, in the end its main purpose is to allow "efficient copying of
binaries across repositories with the same datastore", which seems to me best
fit a core concept related to some specific deployments.
> BinaryReferenceMessage also implements getStream(), read() and getSize() by
> providing the message token - IMHO that is misleading if it is used as
> special interface only. These should probably return null. The repository
> itself would never return such a Binary itself.
that's basically for compatibility with existing code where you may now receive
such an object and you wouldn't expect that to return null.
> Efficient copying of binaries across repositories with the same data store
> --------------------------------------------------------------------------
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core
> Affects Versions: 2.6
> Reporter: Felix Meschberger
> Assignee: Tommaso Teofili
> Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.patch,
> JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global
> data store to prevent sending around and copying around large binary data
> unnecessarily: We have two separate Jackrabbit instances configured to use
> the same DataStore (for the sake of this discussion assume we have the
> problems of concurrent access and garbage collection under control). When
> sending content from one instance to the other instance we don't want to send
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from
> JackrabbitValue.getContentIdentity(). The receiver would then check whether
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
> would allow for round tripping the JackrabbitValue.getContentIdentity()
> preventing superfluous binary data copying and moving.
> See also the dev@ thread
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
