Re: Multi-GET, extreme compression?

[Julian Reschke <[e-mail]>]

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 
<http://www.w3.org/TR/html-markup/input.file.html#input.file.attrs.multiple>. 
No JS needed at all.

Best regards, Julian