Subject: Re: Multi-GET, extreme compression?

From: Julian Reschke <[email-masked]>
Date: Mon, 04 Mar 2013 19:12:34 +0100

On 2013-02-27 17:45, Nicolas Mailhot wrote:
> ...
>> Also, see
>> <http://www.w3.org/TR/html-markup/input.file.html#input.file.attrs.multiple>.
>> No JS needed at all.
>
> Ah, nice, someone finally noticed this part was broken. Pity it's not
> deployed yet.
 > ...

It is in current versions of IE, FF, and Chrome.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Mar 2013 13:22:49 -0500

OK, I can see a case for symmetry here. The main thing though is that
the multiplexing/streaming protocol should allow a configuration in
which either side can send asynchronous collections.

HTTP was originally built on an RPC model where requests and responses
are always one for one. Web Services like chat require other patterns
that are more like opening a channel to get a list of content items
where the length of the list is undefined.

On Wed, Feb 27, 2013 at 10:40 AM, Nicolas Mailhot
<[email-masked]> 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.
>
> --
> Nicolas Mailhot
>
>

-- 
Website: http://hallambaker.com/