On Mon, Sep 4, 2017 at 4:57 PM, Ian Boston <i...@tfd.co.uk> wrote: > Hi, > IIUC There are 2 patterns: > > 1 Emitting a short lived signed URL as per the AWS CloudFront recommended > method of serving private content.
I have nothing to object to choice of AWS CloudFront. The past technological choices were very different. At the time, we were taking about converting a binary to an S3 bucket ID for users to manipulate. This had, as you could understand, a bigger impact on Oak from the point of view of security and data ownership. I am still of the opinion, though, that if S3 and CloudFront are part of the technological stack chosen by a user, it's the user's responsibility to directly interact with it. Oak can transparently manage binaries in S3 for you, as long as it remains transparent. If as a user you need to manipulate buckets, or create CloudFront distributions, or use the AWS infrastructure to replicate S3 buckets in a different zone, then this is part of your business logic. Oak can still be used to store metadata and S3 bucket IDs, but the management of S3 and CloudFront it is up to you. This is just my view on the problem. If our users desperately want Oak to transparently store data in S3 but also to opt out when needed, we are going to provide this functionality. Still, my point of view is that it's wrong. > 2 An Oak internal AdapterFactory/AdapterManager pattern to avoid Oak API. > changes. Sling adapters or a partial implementation of it is too dangerous in its flexibility. Today we are using this system to solve only one problem. Tomorrow we are going to end up like in Sling, where everything might be adapted to everything else and module boundaries will be more difficult to enforce. Sling adapters require too much discipline to get right and are too easy to misuse. Moreover, as soon as you register an AdapterManager in OSGi people are going to get curious. There is no real control in OSGi unless you use subsystems, and we are not using them. The most widely used commercial products based on Oak are not using OSGi subsystems either, and this is just going to exacerbate the problem. My take on this is that it's alright to have something like a OakConversionService, but please don't use a solution based on or inspired to Sling adapters to implement it. It's easier, safer and more controllable to implement this solution ad-hoc. > Would you be willing state your concerns for each one separately ? > > Best Regards > Ian > > On 4 September 2017 at 15:43, Francesco Mari <mari.france...@gmail.com> > wrote: > >> I'm in no position to veto the POC and I'm not willing to. I am well >> aware of the importance of this feature. I expressed my concerns and >> so did others. As the subject of this thread clearly stated, I only >> wanted to point out that I had the feeling that we had a "reboot" of >> the conversation for no good reason, with the unpleasant side effect >> of proposing once again a pattern that received a lot of criticism in >> the past. >> >> On Mon, Sep 4, 2017 at 4:18 PM, Bertrand Delacretaz >> <bdelacre...@apache.org> wrote: >> > On Mon, Sep 4, 2017 at 3:44 PM, Ian Boston <i...@tfd.co.uk> wrote: >> >> ...I feel >> >> that Oak is weaker without the ability to offload bulk data streaming to >> >> infrastructure designed for that purpose.... >> > >> > FWIW as an Oak user I share that feeling, IMO the use cases described >> > at https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase are >> > becoming more and more important. >> > >> > Not being a committer I don't really care about the internals, but >> > please do not "throw the baby out with the bath water" if the >> > internals need to change. >> > >> > -Bertrand >>
