Hi, On 6 September 2016 at 12:14, Marcel Reutegger <mreut...@adobe.com> wrote:
> Hi, > > On 06/09/16 12:34, Bertrand Delacretaz wrote: > >> On Tue, Sep 6, 2016 at 9:49 AM, Marcel Reutegger <mreut...@adobe.com> >> wrote: >> >>> ...we'd still have to add >>> Jackrabbit API to support it. E.g. something like: >>> >>> valueFactory.createBinary(existingBinary, appendThisInputStream); ... >>> >> >> And maybe a way to mark the binary as "in progress" to avoid >> applications using half-uploaded binaries? >> > > This can easily be prevented if the 'in progress' binary is > uploaded to a temporary location first and then copied over > to the correct location once complete. Keep in mind that > copying a large existing binary in Oak is simply a cheap > copy of the reference. > Is that exposed as an API that can be used by Sling ? For the Sling use case it might not be sufficient, as the chunks that are uploaded need to be joined together to form the binary. Streaming to the chunks is supported (in the patch I am working on), concatenating the chunks into a final binary requires copying in and out of the DS. BTW, the Wiki page is immutable so I can't edit. This use case is encapsulated in the documentation of the feature, https://cwiki.apache.org/confluence/display/SLING/ Chunked+File+Upload+Support There are references in there to other implementations, including a AWS S3 API. The Google Drive API is documented here https://developers.google.com/drive/v3/web/manage-uploads They all do a simular thing. Best Regards Ian > > Regards > Marcel >
