> 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. 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) > > >
