On Thu, Sep 7, 2017 at 11:05 AM, Ian Boston <[email protected]> wrote: > On 7 September 2017 at 07:22, Ian Boston <[email protected]> wrote: > >> 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/jackrabbit-oak/compare/trunk...ieb:O >>>> AK-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. >> > > > > > https://github.com/ieb/jackrabbit-oak/compare/trunk...ieb:OAK-6575-3?expand=1 > > and > > https://github.com/apache/sling/compare/trunk...ieb:OAK-6575-3?expand=1 > > wdyt ?
I like this a lot. It keeps Oak's side simple and cleanly integrates Oak's lower-level services in Sling. > Obviously the second patch needs to be discussed with Sling dev, but is > should not be too contentious. > > Best Regards > Ian > > > >> >> 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 >>> >> >>
