On Mon, 22 Jan 2001, Christoph Lameter wrote:

> > * Client-code. Rather than adding lots of weird options to the curl tool, you
> > can often enough clone the entire client code, strip off the stuff you
> > don't want or need and add the things your special condition needs. This
> > would then build a separate executable for this special purpose.
>
> Ok. So you suggest I write a special CLI for the library? The versatile
> existing commands were the prime reasons we started using curl. I dont
> want to get rid of them.

Right, I follow that reasoning and I agree. Then that's not an option. Let's
then instead focus on making the new options generic enough to become useful
for many people and possible have some features #ifdef ENABLE_NETSAINT style.

> > I believe most of what was posted in the initial patch can be added in the
> > third category.
>
> Well that argument can be made for -g. -G needs some changes to the way
> curl buffers data. Otherwise you cannot match on a buffer boundary. Hooks
> would be great but that will not avoid the need to change the buffering
> code.

Could you elaborate on how you want that changed and why a hook wouldn't make
that possible? The hook part would simply take the code off the library and
move it to the client. If the buffer reorganisation could be made in the
library, thus it would be possible to make in a hook.

I would also like to point out that the patch you sent me did make
assumptions about the size of the received data that was incorrect (it copied
100 bytes unconditionally).

> I am not sure how a filtering hook would be able to work? Pass a size and
> pointer to it? Then you would need to read the complete URL into memory
> first.

Why would a hook need that when your previous patch doesn't?

> I hope I have answered that above. The -J option requires a change in the
> analysis of the html code for errormessages and is also not transferable
> to the client.

I don't understand the -J option. Could you elaborate on what it does? I
mean, no one forces you to use -f and then curl won't fail on non-200 HTTP
error codes.

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/