Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Chetan Mehrotra <ch...@gmail.com>]

I have started a new mail thread around "Usecases around Binary handling in
Oak" so as to first collect the kind of usecases we need to support. Once
we decide that we can discuss the possible solution.

So lets continue the discussion on that thread

Chetan Mehrotra

On Tue, May 17, 2016 at 12:31 PM, Angela Schreiber <an...@adobe.com>
wrote:

> Hi Oak-Devs
>
> Just for the record: This topic has been discussed in a Adobe
> internal Oak-coordination call last Wednesday.
>
> Michael Marth first provided some background information and
> we discussed the various concerns mentioned in this thread
> and tried to identity the core issue(s).
>
> Marcel, Michael Duerig and Thomas proposed alternative approaches
> on how to address the original issues that lead to the API
> proposal, which all would avoid leaking out information about
> the internal blob handling.
>
> Unfortunately we ran out of time and didn't conclude the call
> with an agreement on how to proceed.
>
> From my perception the concerns raised here could not be resolved
> by the additional information.
>
> I would suggest that we try to continue the discussion here
> on the list. Maybe with a summary of the alternative proposals?
>
> Kind regards
> Angela
>
> On 11/05/16 15:38, "Ian Boston" <ie...@tfd.co.uk> wrote:
>
> >Hi,
> >
> >On 11 May 2016 at 14:21, Marius Petria <mp...@adobe.com> wrote:
> >
> >> Hi,
> >>
> >> I would add another use case in the same area, even if it is more
> >> problematic from the point of view of security. To better support load
> >> spikes an application could return 302 redirects to  (signed) S3 urls
> >>such
> >> that binaries are fetched directly from S3.
> >>
> >
> >Perhaps that question exposes the underlying requirement for some
> >downstream users.
> >
> >This is a question, not a statement:
> >
> >If the application using Oak exposed a RESTfull API that had all the same
> >functionality as [1], and was able to perform at the scale of S3, and had
> >the same security semantics as Oak, would applications that are needing
> >direct access to S3 or a File based datastore be able to use that API in
> >preference ?
> >
> >Is this really about issues with scalability and performance rather than a
> >fundamental need to drill deep into the internals of Oak ? If so,
> >shouldn't
> >the scalability and performance be fixed ? (assuming its a real concern)
> >
> >
> >
> >
> >>
> >> (if this can already be done or you think is not really related to the
> >> other two please disregard).
> >>
> >
> >AFAIK this is not possible at the moment. If it was deployments could use
> >nginX X-SendFile and other request offloading mechanisms.
> >
> >Best Regards
> >Ian
> >
> >
> >1 http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectOps.html
> >
> >
> >>
> >> Marius
> >>
> >>
> >>
> >> On 5/11/16, 1:41 PM, "Angela Schreiber" <an...@adobe.com> wrote:
> >>
> >> >Hi Chetan
> >> >
> >> >IMHO your original mail didn't write down the fundamental analysis
> >> >but instead presented the solution for every the 2 case I was
> >> >lacking the information _why_ this is needed.
> >> >
> >> >Both have been answered in private conversions only (1 today in
> >> >the oak call and 2 in a private discussion with tom). And
> >> >having heard didn't make me more confident that the solution
> >> >you propose is the right thing to do.
> >> >
> >> >Kind regards
> >> >Angela
> >> >
> >> >On 11/05/16 12:17, "Chetan Mehrotra" <ch...@gmail.com>
> wrote:
> >> >
> >> >>Hi Angela,
> >> >>
> >> >>On Tue, May 10, 2016 at 9:49 PM, Angela Schreiber <an...@adobe.com>
> >> >>wrote:
> >> >>
> >> >>> Quite frankly I would very much appreciate if took the time to
> >>collect
> >> >>> and write down the required (i.e. currently known and expected)
> >> >>> functionality.
> >> >>>
> >> >>> Then look at the requirements and look what is wrong with the
> >>current
> >> >>> API that we can't meet those requirements:
> >> >>> - is it just missing API extensions that can be added with moderate
> >> >>>effort?
> >> >>> - are there fundamental problems with the current API that we
> >>needed to
> >> >>> address?
> >> >>> - maybe we even have intrinsic issues with the way we think about
> >>the
> >> >>>role
> >> >>> of the repo?
> >> >>>
> >> >>> IMHO, sticking to kludges might look promising on a short term but
> >> >>> I am convinced that we are better off with a fundamental analysis of
> >> >>> the problems... after all the Binary topic comes up on a regular
> >>basis.
> >> >>> That leaves me with the impression that yet another tiny extra and
> >> >>> adaptables won't really address the core issues.
> >> >>>
> >> >>
> >> >>Makes sense.
> >> >>
> >> >>Have a look in of the initial mail in the thread at [1] which talks
> >>about
> >> >>the 2 usecase I know of. The image rendition usecase manifest itself
> >>in
> >> >>one
> >> >>form or other, basically providing access to Native programs via file
> >> path
> >> >>reference.
> >> >>
> >> >>The approach proposed so far would be able to address them and hence
> >> >>closer
> >> >>to "is it just missing API extensions that can be added with moderate
> >> >>effort?". If there are any other approach we can address both of the
> >> >>referred usecases then we implement them.
> >> >>
> >> >>Let me know if more details are required. If required I can put it up
> >>on
> >> a
> >> >>wiki page also.
> >> >>
> >> >>Chetan Mehrotra
> >> >>[1]
> >> >>
> >>
> >>
> http://markmail.org/thread/6mq4je75p64c5nyn#query:+page:1+mid:zv5dzsgmoeg
> >>u
> >> >>pd7l+state:results
> >> >
> >>
>
>