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:28:10 +0100
Message-ID: <512E341A.8000809@gmx.de>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
CC: ietf-http-wg@w3.org
On 2013-02-27 17:20, Julian Reschke wrote:
> 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

Also, see 
No JS needed at all.

Best regards, Julian
Received on Wednesday, 27 February 2013 16:28:39 UTC

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