> 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. Chetan Mehrotra On Thu, Aug 24, 2017 at 5:41 AM, Michael Dürig <mdue...@apache.org> 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 <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) >>> >>> >>> >>> >
