Hi, On 11 May 2016 at 14:21, Marius Petria <[email protected]> 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" <[email protected]> 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" <[email protected]> wrote: > > > >>Hi Angela, > >> > >>On Tue, May 10, 2016 at 9:49 PM, Angela Schreiber <[email protected]> > >>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:zv5dzsgmoegu > >>pd7l+state:results > > >
