On Tue, 9 Dec 2003, DOMINICK C MEGLIO wrote:

> >There are perfectly fine URL/URI libraries already, and if there isn't one
> >that suits you I'm sure you can make one pretty swiftly that will.

> Yeah of course. But what I meant by "wasteful" is I would be including
> libwww, which as I'm sure you know, is a rather large and robust library,
> just to have one function. To me, making my users download a 1MB file for a
> 300byte function is wasteful.

I don't think libwww is the only available library that can parse URLs and
return the file name part for you. I fully agree that linking with libww for
the sole purpose of parsing URLs, is a waste.

> curl_checkproto:

> This seems like a good idea to me I guess. However, this kind of seems
> exactly like what you just told me you didn't want to add. I.e. the "why
> stop at just filenames?,"

I agree that this suggestion borders to what I object against, but I see a
clear distinction: checkproto would be focused on returning what protocol
libcurl would USE on the given URL. Not necessarily what the protocol part
says, and it would return not-supported if the specified protocol part isn't.

Thus, it isn't just about parsing the URL and returning the protocol part.

> well, "why stop at just protocols?" Meaning I can already tell if curl
> supports a protocol, curl_easy_perform will return
> CURLE_UNSUPPORTED_PROTOCOL, so that functioning already exists.

Not quite, as then you'd also get the URL transfered if you provided a URL
with a supported protocol.

You could however use the curl_version_info() to extract most of this info,
yes, but then you still wouldn't know for sure what protocol libcurl will use
when specifying a host name like 'curl.haxx.se' or 'ftp.sunet.se'. This
function would tell.

> A function like curl_checkproto however is designed to work directly on a
> URL (at least that's what I assume since you didn't like my method because
> it worked on an easy handle). Therefore, what's the difference between
> parsing a URL to determine the protocol and parsing a URL to determine the
> filename?

The connection between the given URL and how libcurl works. Code to extract
the file name part needs no knowledge whatsoever about libcurl internals.

> Anyway, hopefully this is at least one idea you will like :) I've attached a
> patch that allows the user to specify a path for ares.

Thanks! I've applied, verified and committed it.

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click