Re: sapi_header_op

Thanks for the clarifications. IMHO the advantage does not outweigh the disadvantages (slower, more cumbersome to use, will require everyone to implement two interfaces), so personally, I'm -1. Zeev At 06:30 PM 6/30/2002, Sascha Schumann wrote:

How is it better than add_header_ex()?

    1. The function name misrepresents the function's task.
       It sets the response code, replaces or adds a header.
       Simply calling it 'operation' is therefore a clearer
       choice.

    2. The new function has a more generic interface which I
       prefer over sapi_add_header_ex, sapi_add_header7 and so
       on.  This interface can be extended without adding new
       APIs.  In the case of SAPI_HEADER_ADD/REPLACE, source code
       level compatibility is guaranteed by initializing the
       parameter as

            sapi_header_line ctr = {0};

       so that additional fields are properly initialized as zero.

    3. It also addresses a design issue of the sapi_add_header
       interface.  The new function never deallocates memory
       which was allocated by the caller.  The impact of
       duplicating 1-2 strings per request does not outweigh
       violating a basic design principle IMHO.

    - Sascha