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 <mdue...@apache.org> 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)
