From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wkgbm-0004lI-E9 for qemu-devel@nongnu.org; Wed, 14 May 2014 17:21:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wkgbh-0003I3-Go for qemu-devel@nongnu.org; Wed, 14 May 2014 17:21:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wkgbh-0003Hq-7J for qemu-devel@nongnu.org; Wed, 14 May 2014 17:20:57 -0400 Message-ID: <5373DE34.9090402@redhat.com> Date: Wed, 14 May 2014 17:20:52 -0400 From: Matthew Booth MIME-Version: 1.0 References: <1399538540-5076-1-git-send-email-mbooth@redhat.com> <537276C6.5010308@redhat.com> <20140514074817.GB3610@noname.redhat.com> <5373951B.4080609@redhat.com> <20140514164351.GP3610@noname.redhat.com> In-Reply-To: <20140514164351.GP3610@noname.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Curl updates List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/05/14 12:43, Kevin Wolf wrote: > Am 14.05.2014 um 18:08 hat Matthew Booth geschrieben: >> On 14/05/14 03:48, Kevin Wolf wrote: >>> Am 13.05.2014 um 21:47 hat Eric Blake geschrieben: >>>> On 05/08/2014 02:42 AM, Matthew Booth wrote: >>>>> [PATCH 1/4] curl: Fix parsing of readahead option from >>>>> filename [PATCH 2/4] curl: Add sslverify option [PATCH >>>>> 3/4] curl: Add usage documentation >>>>> >>>>> The first 3 patches are reposted with updates following >>>>> discussion of the option syntax. With this patch I've >>>>> decided to break entirely with the previous syntax. Given >>>>> that option parsing was previously both broken and >>>>> undocumented, this is hopefully a forgivable sin. >>>>> >>>>> The new syntax is: >>>>> >>>>> http://user:password@example.com/path?query[opt1=val:opt2=val] >>>>> >>>>> >>>>> I've bounded the option block in square brackets as these have >>>>> no semantic meaning in any of the supported URI formats. >>>> >>>> Offhand, I'm not liking this. Why not use a completely >>>> valid URI, with '.../path?query&opt1=val&opt2=val'? >>>> Inventing your own [opt1=val:opt2=val] on top of URI is >>>> asking for confusion. >>>> >>>> Are you trying to support a way to pass a query string to >>>> the curl URI, in addition to local options? How often do >>>> curl URIs need a query? >>> >>> My guess would be that you need this more often than local >>> options. >>> >>> Anyway, let's not add new options encoded in the URL, but >>> point users to separate options. We may decide that we need the >>> support the old crude way of encoding local options for >>> compatibility, but preferably I would make filename just a >>> plain URL. >> >> Agree, but only when we support giving options to a backing >> file. > > Right, but we want that anyway. I applied Max's patches for the > json: pseudo-protocol today, so we should have everything we need. I can't see this in block/master. Am I looking in the wrong place? Matt > > Kevin > - -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNz3jQACgkQNEHqGdM8NJBBNACeKipCLadTv1+AANVJzLrMcJmU q0IAnREbaaT3LVXaIYr09eej04mzvokG =bEUQ -----END PGP SIGNATURE-----