On 04.09.17 16:57, Ian Boston 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 think this is an area where your patch made a lot of progress. From
your description my initial concerns in this area have been mostly
addressed (e.g. no more leakage of implementation details). A missing
bit would be clarification how this feature interacts with other
features like active blob deletion / garbage collection. However I think
it is fine to address those via documentation once we have a full
understanding.
2 An Oak internal AdapterFactory/AdapterManager pattern to avoid Oak API
changes.
This is the area where some of us were taken by surprise. I'm fine with
the current solution ("the conversion service") even though I would have
preferred "the OakValueFactory" approach, which IMO is more consistent
with the rest of the Oak API. My main concern with this kind of APIs is
that it in a way circumvents statical type safety and along with it
statical code analysis (e.g. re. backwards compatibility). OTOH Sling is
using similar patterns successfully a lot and moving closer to our main
API consumer is not a bad thing. Also IIUC the conversion service might
in future line up nicely (and maybe even be replaced by) similar OSGi
functionality!?
Michael
Would you be willing state your concerns for each one separately ?
Best Regards
Ian
On 4 September 2017 at 15:43, Francesco Mari <[email protected]>
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
<[email protected]> wrote:
On Mon, Sep 4, 2017 at 3:44 PM, Ian Boston <[email protected]> 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
