cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: Patch for Metalink Support

From: Tatsuhiro Tsujikawa <tatsuhiro.t_at_gmail.com>
Date: Fri, 06 Mar 2009 00:47:44 +0900

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Fandrich wrote:
> On Tue, Mar 03, 2009 at 11:54:34PM +0900, Tatsuhiro Tsujikawa wrote:
>> Finally, I created 2nd patch.
>> I tried to put metalink functions in a separate file, but many
>> convenient functions and struct is defined in static in main.c(are there
>> any plan to make these functions non-static?), in this patch, sorry but
>> I put all metalink functions in main.c. The actual metalink download
>> code is separated from the original function(operate function), making
>> the existing code as unchanged as possible.
>
> I've been thinking about this feature in light of the scope that the curl
> tool sets for itself, and I have a suggestion. The curl tool has always
> been designed in the UNIX tradition of small, lightweight tools that can
> work together to accomplish something bigger. The suggestion was made
> on this list that Metalink support could be added to curl similar to how
> ssh support was added to rsync; by treating the app as a wrapper around the
> low-level tool, and shells out to call it when appropriate.
>

(Firstly, I'm sorry for top-posting in the previous mail. I noticed it
but it was too late..)

I agree that the design philosophy has great impact on the open source
project. The wrapper program, something called "metacurl", which parses
Metalink files and calls curl inside, will more suite the spirit of curl.

> That idea has some merit, but here's another. This isn't the only "large"
> feature that has been proposed for curl. Others include recursive download
> support (which requires HTML parsing support), ftp wildcard support (which
> requires parsing FTP directories), automatic proxy configuration (which
> requires Javascript support), and pipelined and simultaneous download support
> (which requires use of the multi interface). Maybe it's time to propose a
> new project, call it "MegaCurl", that doesn't have the self-imposed
> restrictions on what the curl command line should do and sits
> alongside it.

Taking into account that the wide spread use of libcurl, "MegaCurl" will
be a promising project.

I created the patch as a response to Daniel's request:

Daniel Stenberg wrote:
> >> On Sat, 13 Dec 2008, Tatsuhiro Tsujikawa wrote:
> >>
> >> I would like to play around with this patch and functionality a bit,
> >> but I have an initial request:
> >>
> >> I'd like this patch to have as low impact as possible on the existing
> >> code so I would really like to see perhaps a separate file added with
> >> the necessary metalink support functions or similar, so that all devs
> >> and users who don't care for metalink wouldn't have to see many traces
> >> of it.
> >>

So, I want to hear his opinion too.

Best regards,

Tatsuhiro Tsujikawa

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmv9CAACgkQfoQD1dZzw2YjywCaA11n3QmwZULbZyf/+f0TfQXJ
+X0AoJs41aYah2EfuEeLgFWvV0ViO9nF
=TC97
-----END PGP SIGNATURE-----
-------------------------------------------------------------------
List admin: http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-03-05