> Why couldn't we discuss this implementation in the light of the OAK-1963? > Why the old concerns are not taken in to consideration once again? We already > talked about all that.
I closed OAK-1963 because it was specially related to exposing the File instance url while objective of OAK-6575 is to provide a secure url. My reading of discussion done in OAK-1963 that people had concern around exposing the File instance location managed by Oak. Adaptable pattern in itself was not much discussed at that time. Hence it made sense to close OAK-1963 and have a fresh discussion on OAK-6575 As for OAK-6575 the approach taken there has been discussed in detail at [1] and in the end there was consensus on the proposed approach by Ian. Chetan Mehrotra [1] http://markmail.org/thread/lhljp2ksegw7dcod On Mon, Sep 4, 2017 at 5:25 PM, Francesco Mari <[email protected]> wrote: > The POC for OAK-6575 aims at introducing the AdapterManager and > AdapterFactory API in Oak. This is just a step away from introducing a > full-fledged implementation of Sling-like adapters in Oak. In fact, > the OakConversionService is just an Adapter for a single, very > specific conversion. > > We had a very similar conversation for OAK-1963 in a thread [1] in > this mailing list. In that thread many people raised that concerns > about adapters. Many of us, me included, see adapters as a glorified > way of breaking data encapsulation and are not in favour of > introducing them. > > After some quiet time in the thread and in OAK-1963, a new thread [2] > was created, a new issue [3] was opened and a POC [4] was written. The > content of the POC is little more than a permutation of what was > already discussed in OAK-1963. Why a new thread and issue were needed? > Why couldn't we discuss this implementation in the light of the > OAK-1963? Why the old concerns are not taken into consideration once > again? We already talked about all that. > > If the majority of the people here is alright in going forward with > the aforementioned POC, so be it. But, at least, let's avoid closing > threads and issues and create new ones that are just carbon copies. > This might be misinterpreted as a way to clear concerns out of our > way. > > [1]: http://markmail.org/thread/enmibgfwedypjnos > [2]: > https://lists.apache.org/thread.html/2efb1da82b9b93a3a394c3abccbac960175ffc7a13facaac79c9181a@%3Coak-dev.jackrabbit.apache.org%3E > [3]: https://issues.apache.org/jira/browse/OAK-6575 > [4]: > https://github.com/apache/jackrabbit-oak/compare/trunk...ieb:OAK-6575?expand=1
