On Sun, 7 Dec 2003, DOMINICK C MEGLIO wrote:

Thanks for your suggestions! Here's my personal opinions about them... As
always, I'm open for and listening to what others think!

> 1.) CURLOPT_URLENCODE
>
> If specified this will force libcurl to automatically URL Encode the URL.
> Encoding a URL isn't as simple as running it through curl_escape. For
> example, curl_escape will encode the :// part of the http://. This means I
> must first split the URL apart, do the escaping, then rejoin it. It seems
> stupid to do all that when the splitting apart is already done by libcurl
> internally, why not just allow it to encode the URL for the user? I'm sure
> this is something that many people would find useful since it would simplify
> getting files from a URL.

I'm against adding this feature because it misleads people into believing
libcurl will do the right thing for them, when in fact libcurl can't know how
to properly url encode something that is already put together into a "URL" (it
won't really be a url if it isn't encoded properly).

> 2.) CURLOPT_DISABLEPROTOCOLS
>
> Basically this is a runtime version of things like --disable-telnet. You
> specify an slist that contains the names of the protocols you want disabled.
> This is useful because, while --disable-telnet does the same thing, what if
> Program1 wants just telnet:// and Program2 wants just http://, why should
> there need to be two seperate libraries compiled? It seems to me that doing
> this at runtime is the way to go. And yes, this could be done rather easily
> in the client application (which is how I currently do it), it seems like it
> should be in the library itself.

The idea behind these build-time options to disable certain protocols, was to
offer users a way to reduce the size of the output library by disabling
features they don't use. I didn't realize it would be considered a useful
run-time option.

I figure this would need to be bits set in curl_global_init() for this to be
really useful?

> 3.) curl_getfilename(CURL *curl);
>
> Getting the filename can be rather difficult. You need to be very familiar
> with the URL scheme. Meaning you need to know where the file is located in
> the URL itself. Why should the client programmer need to have intimate
> knowledge of the URLs? Isn't that what the library is supposed to handle?

If you replace 'the' with 'a' in that last sentense, then I would agree with
you. This has been discussed at length before.

Why settle with getting just the file name? What about host name? Port number?
Protocol? Password? etc etc... (and then someone comes up with the brilliant
idea of having functions that let you set one of those fields)

I prefer to not offer any of these pieces, and if you want them extracted from
the URL, you can use one of the existing URI/URL parsing libraries "out
there". You know the full URL yourself.

> And for all I know, maybe in version 7.20.0 curl will have support for
> fake://

I've been contemplating about adding a function that when given a URL it
returns info about libcurl's support of that particular protocol.

> which uses something completely different maybe,
> fake://host.com/download,file.txt. When I created my program, fake:// didn't
> exist, but when 7.20.0 is released, maybe it does.

One of the ideas behind the concept of URLs is that they look and work the
same, independent of the underlying protocol. Thus, you should be pretty safe
to assume that no such big surprises will pop up even in future versions of
libcurl.

-- 
    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