Re: Multi-GET, extreme compression?

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