W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Multi-GET, extreme compression?

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 27 Feb 2013 17:20:29 +0100
Message-ID: <512E324D.40802@gmx.de>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
CC: ietf-http-wg@w3.org
On 2013-02-27 16:40, Nicolas Mailhot wrote:
> Julian Reschke <julian.reschke@...> writes:
>> On 2013-02-27 11:16, Nicolas Mailhot wrote:
>>> James M Snell <jasnell@...> writes:
>>>> Fair enough
>>> There is a similar need for mput/mpost, the fact current web apps require
>>> a separate user sequence for each file a user wants to publish/attach to a
>>> message is one of the few remaining use-cases where they suck compared to
>>> local apps.
>> But that's UI (HTML/JS), not protocol, right? Also, that's solvable; I
>> happen to be in a project where our web app supports bulk upload of
>> files by drag & drop to the browser window...
> That's just another workaround, where you paper over the missing feature with
> gobs of site-specific javascript and by pretending the average user
> drag-and-drops files in apps. I've seen the same demoware years ago it does not
> work out in real life.
> The average user does not drag and drop he uses the file selector, that maps to
> standard html forms, that maps to what the protocol knows to do (one element at
> a time). In browsers the file selector is restricted to single file selection to
> respect what non-js-extended http/html ecosystem allows.
> And, lastly, most web app developpers will not bother with loads of feel-good js
> workarounds since what the users want is their default file selector, not some
> kind of js emulation.

I still don't understand what the constraints of the browsers have to do 
with the protocol. Browsers use multipart uploads, and those allow 
multiple files already. What am I missing?

Best regards, Julian
Received on Wednesday, 27 February 2013 16:21:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC