On 24.08.17 14:47, Chetan Mehrotra wrote:
Which circles back to my initial concern: "According to YAGNI we should stick with
instance of checks unless we already have a somewhat clear picture of future
extensions."
I thought that with all those discussion around JCR Usecases for past
some time we have an agreement for such cases (specially UC3 and UC4).
Hence the push for this approach to enable further work on them going
forward.
I wasn't referring to those use cases but to the adapter pattern. That
pattern as it was proposed here is far more general than what is
required for the problem at hand. It represents a shift in paradigm of
what we used to do in Oak. That's why I asked for a "somewhat clear
picture of future extensions". Introducing the adapter pattern in its
full generality would IMO even deserve an own discussion thread instead
of being piggy backed on the secure URL discussion.
Michael
Chetan Mehrotra
On Thu, Aug 24, 2017 at 5:41 AM, Michael Dürig <[email protected]> wrote:
On 24.08.17 14:32, Chetan Mehrotra wrote:
Why not just add a method Blob.getSignedURI()? This would be inline with
getReference() and what we have done with ReferenceBinary.
Can be done. But later if we decide to support adapting to say
FileChannel [1] then would we be adding that to Blob. Though it may
not be related to different Blob types.
Having adaptable support allows to extend this later with minimal changes.
Which circles back to my initial concern: "According to YAGNI we should
stick with instance of checks unless we already have a somewhat clear
picture of future extensions."
Michael
Chetan Mehrotra
[1] https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase#UC4
On Thu, Aug 24, 2017 at 5:25 AM, Michael Dürig <[email protected]> wrote:
On 24.08.17 13:38, Chetan Mehrotra wrote:
various layers involved. The bit I don't understand is how the
adaptable
pattern would make those go away. To me that pattern is just another
way
to
implement this but it would also need to deal with all those layers.
Yes this adapter support would need to be implement at all layers.
So call to
1. binary.adaptTo(SignedBinary.class) //binary is JCR Binary
2. results in blob.adaptTo(SignedBinary.class) //blob is Oak Blob.
Blob interface would extend adaptable
Why not just add a method Blob.getSignedURI()? This would be inline with
getReference() and what we have done with ReferenceBinary.
Michael
3. results in SegmentBlob delegating to BlobStoreBlob which
4. delegates to BlobStore // Here just passing the BlobId
5. which delegates to DataStoreBlobStore
6. which delegates to S3DataStore
7. which returns the SignedBinary implementation
However adapter support would allow us to make this instance of check
extensible. Otherwise we would be hardcoding instance of check to
SignedBinary at each of the above place though those layers need not
be aware of SignedBinary support (its specific to S3 impl)
