Hi, On 4 September 2017 at 16:43, Francesco Mari <mari.france...@gmail.com> wrote:
> 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. > agreed. > > 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. > agreed. Users can, to some extent already use CloudFront, but they have to make all the content public to all users to do so. If anyone uses this patch, they do so because they desperately want to have assets securely served as private content by cloudfront. To do so, they will have to go some deployment effort, generating the correct private keys and configuring the various AWS components etc etc > > > 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. > The Oak AdapterManager was written to work in both OSGi and non OSGi environments as guided by Chetan. A previous version of the patch used a static factory pattern (AdapterManager.getInstance()) and no OSGi at all. There are probably several other patterns, all non OSGi that would stop anyone outside Oak using it. Would a non OSGi pattern address your concerns ? > > 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. > Do you mean: keep the OakConversionService but put all the logic to convert from a Value to a URI inside that implementation using new Oak SPI/APIs if necessary and drop the AdapterManager completely ? This would mean something the datastore implementation implements which oak-core can navigate to would have to implement a mix in interface with a getURI() method. I am not certain what or how without trying to do it. Would that address your concern here ? Best Regards ian > > > 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 > >> >
