On Mon, Jan 22, 2001 at 09:03:45AM +0100, Daniel Stenberg wrote:
> I would happily include features and patches to curl that makes it great to
> use with netsaint and other tools as previously described. I do however have
> certain requirements on such features:
>
> * Unconditional (without #if or #ifdef) code in the library should be general
> features. I'm sure several of the netsaint-ideas could be made more
> generic and added like this to the library.

Yes. I can do so easily.

> * Code that relies on specific conditions or user demands shall be
> conditional, and we add an --enable-feature flag to configure to switch on
> that particular feature set. Like kerberos-ftp and https work already.

Ok.

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

> 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.
 
> I'm indeed open to add "hooks" to the library that would allow the client to
> add "filtering" functionality like regex-searching. I would imagine that the
> client sets a hook before a download and then the specified "filter-function"
> gets called by the library during download to do the filtering the client
> wants.

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.

> The initial patch added 3 rather independent features. -g, -G and -j. -g
> changed the output, -G added regex-searching and -j somehow changed the
> treatmeant of the error code. Which of these really require library changes?

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.

Greetings,

        Christoph Lameter,
        Architect siteROCK Corporation
        Faculty of the University of Phoenix
Received on 2001-01-23