curl-users
Re: Metalink support patch for curl
Date: Thu, 21 Jun 2012 01:48:39 +0900
On Wed, Jun 20, 2012 at 5:23 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Mon, 18 Jun 2012, Tatsuhiro Tsujikawa wrote:
>
>>> $ curl 'http://curl.haxx.se/metalink.cgi?curl=tar.gz'
>>>
>>> This downloads Metalink XML and prints it in stdout and nothing more.
>>> If we instruct curl to save it in the disk, e.g., -O option, it parses
>>> downloaded file as Metalink (if the Content-Type indicates Metalink)
>>> and downloads URIs described there. So the following command line:
>>>
>>> $ curl -O 'http://curl.haxx.se/metalink.cgi?curl=tar.gz'
>>>
>>> will actually download Metalink file and the URI described there.
>>>
>>> Does we need --metalink like switch in this case too?
>
>
> Yes. I think default should be to just get the data, just like it would
> without metalink support.
>
>
>> If the answer is yes, we perhaps make --metalink take no argument and make
>> it a switch to toggle further metalink parsing. So the last example command
>> line will become:
>>
>> $ curl --metalink -O http://.../file.metalink
>>
>> The --metalink is also used to toggle upcoming metalink/http feature.
>
>
> Yes, I think that would make perfect sense.
>
>
>> For reading local metalink file, new option --metalink-file will be added.
>
>
> Hm, do you really need a separate option for that? Won't it just be a
> file:// URL instead pretty much?
>
Agree.
The attached patch does what we discussed here: --metalink is now
non-argument option and if it is specified, process given URI as
Metalink XML file.
I dropped Content-Type sniffing because now users has total control of
whether parsing or not parsing file as Metalink. If URI is file://,
then we don't have Content-Type at the first place.
This patch also takes into account of Gunter's concern:
> perhaps lets store the metalink data in a temp file, and remove it afterwards;
> there's no need to clutter local disk with that stuff once the download finished
> successfully ...
I think this makes sense because if --metalink is given, user wants
the URI described in Metalink file and not Metalink file itself.
In this patch, Metalink specific write function is passed to libcurl
CURLOPT_WRITEFUNCTION option and downloaded data is directly fed into
libmetalink's XML parser. So no local file involved this time.
So you can now download remote metalink like this:
$ curl --metalink 'http://curl.haxx.se/metalink.cgi?curl=tar.bz2'
No worry about '?' characters this time, because it is not written to the disk.
You can also process local file using file://:
$ curl --metalink file://curl.metalink
0001 patch contains referctoring to reduce memory copy when multiple
checksum is provided.
0002 patch contains the changes I mentioned above.
0003 patch restores noprogress and isatty config values in each download.
This might be a bug fix.
0004 patch adds Metalink test case. Please forget about my previous
mail about Metalink test cases.
# It turns out that --metalink cannot be used to enable Metalink/HTTP
feature, so it
# seems we need another option for it, but it is another story.
Best regards,
Tatsuhiro Tsujikawa
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-users
> FAQ: http://curl.haxx.se/docs/faq.html
> Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
- application/octet-stream attachment: 0004-Added-Metalink-test-case.patch
- application/octet-stream attachment: 0003-Restore-noprogress-and-isatty-config-values.patch
- application/octet-stream attachment: 0002-Made-metalink-option-toggle-Metalink-functionality.patch
- application/octet-stream attachment: 0001-Refactored-metalink_checksum.patch