On Mon, Jun 11, 2012 at 6:00 AM, <curl-users-request_at_cool.haxx.se> wrote:
> Date: Mon, 11 Jun 2012 01:35:51 +0900
> From: Tatsuhiro Tsujikawa <tatsuhiro.t_at_gmail.com>
> To: the curl tool <curl-users_at_cool.haxx.se>
> Subject: Re: Metalink support patch for curl
> Message-ID:
>       >
> The attached patch adds 2 Metalink test cases.

Tatushiro,

thank you for doing the test cases.

(also thanks to bagder, yangtse, & gknauf on github! I noticed you
helped with various metalink changes.)

I saw that 'curl URI_to_meta4 -O' downloads the .meta4 file while
'curl URI_to_metalink3 -O' downloads and parses the metalink and
downloads from the mirrors. 'curl --metalink' with local meta3/4 both
work.

you said:

> This is because parsing Metalink is triggered by Content-Type and
> currently metalink4 content type is not supported. The fix is just add
> the code to check metalink4 type too.

can you do that so .metalink and .meta4 both behave the same way?

could you also add transparent Metalink support triggered with
Link header to metalink file as well, as in RFC 6249:

Link: <http://example.com/example.ext.meta4>; rel=describedby;
   type="application/metalink4+xml"

> I did not have Metalink/HTTP in mind in this patch set, but thanks to
> GSOC, KGet and Wget(?) receive this feature so it would be good to
> bring it into curl too.

it would be nice to all come out together if possible.

> The good side of Metalink/HTTP is it does not need libmetalink (XML
> parser thing).
> First I'll do some refactoring of the current patch to reuse code
> between Metalink/XML and Metalink/HTTP.
> Current code depends on the structs which come from libmetalink all
> the way down to the path.
> To share the code cleanly, I'll introduce new structure and copy the
> needed data from libmetalink structs to our new structs. We use this
> new structs in tool_operate.c. The good side effect of this move is
> that it reduces #ifdefs
> since our new struct does not depend on libmetalink.

ok.

> Since we need to parse Link header field, my --dump-header fix patch
> should be landed before actually doing
> Metalink/HTTP work.

did this land yet?

Daniel,

do you want Metalink/HTTP support off by default, even though it will
not have other dependencies (like libmetalink for XML), just the usual
crypto libs for hash verification used by other features if available?

thinking about it, do we want a --metalinkoff or equivalent so you
could download a metalink file but not process it or turn off
Metalink/HTTP?

also, let me sum up where we are now. things left undone:

1) Metalink/XML support triggered by metalink4 Content-Type
2) Metalink/XML support triggered by HTTP Link header field (as
mentioned in RFC 6249)
3) Metalink/HTTP (RFC 6249)
4) NSS for hash verification. could someone help with this?
5) parallel downloads (as mentioned on your blog). could be nice.
6) use of partial file hashes from Metalink/XML to re-download a part
of the file if it contains errors (I don't think the current patches
support this).
7) I also need to update some of the documentation

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads
-------------------------------------------------------------------
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