Clearly, benefits, but I do wonder what can of worms this opens with regards to confidentiality. "Wait, someone else uploaded this?"
There is also talks about being able to update content (which I personally dislike) - but your proposal adds quite a bit of complexity there too. >From a storage perspective, the component can de-dupe content like you propose, without this being visible to the end-user. That would not prevent the retransmission of the same data though. On 8 September 2017 at 12:05, Remko Tronçon <[email protected]> wrote: > Hi, > > A server may want to provide optimized write-once storage of files that > stores data based on hashes of file contents (such that identical files are > only stored once, and that filenames are opaque). In this light, I was > wondering whether the following extensions to XEP-0363 would make sense: > > - Provide a hash of the contents in the <request>, such that the server > can make decisions on upload slot response based on the hash (e.g. give a > response that this file has already been uploaded). > - The ability to omit the <get> from the slot response, and have it be > returned as the HTTP PUT response, such that the server can delay deciding > what the GET URL will be after it has seen the contents). > > thanks, > Remko > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
