Hi, On 6 September 2017 at 22:43, Michael Dürig <[email protected]> wrote:
> > > On 06.09.17 23:08, Michael Dürig wrote: > >> >> Hi, >> >> On 05.09.17 14:09, Ian Boston wrote: >> >>> Repeating the comment to on OAK-6575 here for further discussion. 2 new >>> Patches exploring both options. >>> >> >> I would actually prefer the original patch (https://github.com/ieb/jackra >> bbit-oak/compare/trunk...ieb:OAK-6575?expand=1) in most parts. However I >> have concerns regarding the generality of the new OakConversionService API >> as mentioned in my previous mail. I would be more comfortable if this could >> be restricted to something that resembles more like a "URIProvider", which >> given a blob returns an URI. >> >> On the implementation side, why do we need to introduce the adaptable >> machinery? Couldn't we re-use the Whiteboard and OSGiWhiteBoard mechanisms >> instead? I think these could be used to track URIProvider instances >> registered by the various blob stores. >> >> > See https://github.com/mduerig/jackrabbit-oak/commit/2709c097b01 > a006784b7011135efcbbe3ce1ba88 for a *really* quickly hacked together and > entirely untested POC. But it should get the idea across though. Thank you. That makes sense. I think it only needs the java/org/apache/jackrabbit/oak/blob/cloud/aws/s3/CloudFrontS3SignedUrlAdapterFactory.java and the API to be inside Oak, everything else can be in Sling. I'll update my patch and do a 2 options for Sling. I think that should address others concerns since it drops all signs of any generic object to object conversion from Oak (Francesco), and doesn't require wide scale fragile changes with implied requirements being placed on how intermediate classes are connected and behave (mine). Best Regards Ian > > Michael >
