Re: Multi-GET, extreme compression?

Phillip Hallam-Baker <hallam@gmail.com> Mon, 04 March 2013 18:24 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9C721F8DE5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 4 Mar 2013 10:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeo5bRRh9WLi for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 4 Mar 2013 10:24:52 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id AF8BD21F8E0B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 4 Mar 2013 10:24:52 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UCa2w-00014u-IX for ietf-http-wg-dist@listhub.w3.org; Mon, 04 Mar 2013 18:23:34 +0000
Resent-Date: Mon, 04 Mar 2013 18:23:34 +0000
Resent-Message-Id: <E1UCa2w-00014u-IX@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1UCa2i-0000pJ-RK for ietf-http-wg@listhub.w3.org; Mon, 04 Mar 2013 18:23:20 +0000
Received: from mail-wi0-f169.google.com ([209.85.212.169]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1UCa2e-0003iS-9p for ietf-http-wg@w3.org; Mon, 04 Mar 2013 18:23:20 +0000
Received: by mail-wi0-f169.google.com with SMTP id l13so2575386wie.0 for <ietf-http-wg@w3.org>; Mon, 04 Mar 2013 10:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ABM4GvHfijQZWwXKRkyAXhYPmCGkVNRmz9oecv0htgY=; b=Tk4sv7FDg4xjulQ85RxitmmHauLeXFrlHqZVA028DENzF/B6z5FaPw64w052/5Hbu0 bbQ2tYY0/7xC8tXbmZP/Rxj5L8dR3aSM//ZPVXS1bCfM/qm+WD9KeP5+mXrrYCcwGcdr ilEM8hlp1aNST4ovitqiqY78AgP8EuhV0Saj6lNmb/cZKG4Onbo0NvdlOUDJEPqnlwzf 89F8EdgwERnGsa+cYhbIWlaVjXpKtmJ1G88mUDQcxwidbLg1V/P8Pdm3n2wuR6RFck8A 5Sb3NUqGfvir+805u5ANt+T6HBlUK6F6xmjSIC6TUdCGzwaXFhS/U+aNkUGkvKedKqK8 FzYg==
MIME-Version: 1.0
X-Received: by 10.194.63.240 with SMTP id j16mr33833368wjs.45.1362421370048; Mon, 04 Mar 2013 10:22:50 -0800 (PST)
Received: by 10.194.11.71 with HTTP; Mon, 4 Mar 2013 10:22:49 -0800 (PST)
In-Reply-To: <loom.20130227T162930-922@post.gmane.org>
References: <CAMm+LwiF6EM8_aQgUm=nPS5XqaG25iRGNke_rnHTM1vTGMXdfg@mail.gmail.com> <A6A82B6EF92590887D2A23D5@cyrus.local> <D9118B58-F53F-4F75-8292-2B990172E234@opengroupware.org> <CABP7RbcX2OqttZuYeuYxhyOgE_ax0M67L1ywPy_VDpW1upM69Q@mail.gmail.com> <CAP+FsNeWDBTBYJ0P-URbO5avbUno5etKid10RM+dRwDWAUys2w@mail.gmail.com> <CABP7RbfVvZnYPPsRvzmC0BtCiPBxQmYXHTRKtq8XE7Z2wY2EfA@mail.gmail.com> <CAA4WUYioRAOEbjU32yEaJuWDAySiZF=OfKXcF-8esqTP0uqwtQ@mail.gmail.com> <968F329C-B6CF-4129-B816-DC56C834A4A4@opengroupware.org> <CAA4WUYgGiJmtbswzmXWi-Ob+1HmoGnMhwr+9j9b5KS5OVQQdjQ@mail.gmail.com> <2DA0834D-C0B7-4A26-B6AD-B5789D0CFA3B@opengroupware.org> <999F9463-660A-42FC-A11C-39CDE95CC616@mnot.net> <D70BFCAB-D2C1-4C66-994F-0C53F6C66581@opengroupware.org> <loom.20130227T111123-907@post.gmane.org> <512DE10E.4090200@gmx.de> <loom.20130227T162930-922@post.gmane.org>
Date: Mon, 04 Mar 2013 13:22:49 -0500
Message-ID: <CAMm+LwhiNHKGWFz6ch6qy23-W8dZD7-PDS-EyxWSjZFRRcX=Zw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Cc: ietf-http-wg@w3.org
Content-Type: text/plain; charset="ISO-8859-1"
Received-SPF: pass client-ip=209.85.212.169; envelope-from=hallam@gmail.com; helo=mail-wi0-f169.google.com
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=-1.754, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UCa2e-0003iS-9p ea2d8ca0ad85ef89897a947861da03c1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Multi-GET, extreme compression?
Archived-At: <http://www.w3.org/mid/CAMm+LwhiNHKGWFz6ch6qy23-W8dZD7-PDS-EyxWSjZFRRcX=Zw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/16969
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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
<nicolas.mailhot@laposte.net> 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/