[cgiapp] Re: concerns with new header_props

[Mark Stosberg <suppressed>]

On 2003-11-09, Cees Hek <suppressed> wrote:
> Quoting Mark Stosberg <suppressed>:
>
>> >> header_props  - works as is
>> >
>> > Keeping header_props unchanged sounds like a good idea in order not to 
>> > break things.
>> 
>> I think I prefer to move forward with allow header_props to be called
>> multiple times. 
>> 
>> >> header_add    - add a header of this type to the current list
>> >> header_set    - replace the current header of this type
>> 
>> I don't think we need these when header_props can be called more than
>> once. I think we just need "add_cookie" to add additional cookies.
>
> By adding a method that is specific to one HTTP header, we are limiting
> ourselves in the flexibility of the API.  I will agree that Set-Cookie is the
> only commonly used header that appears multiple times in a Response header.  But
> what happens when another header comes out that can appear multiple times?
>
> I had a quick read of the RFC for HTTP 1.1, and it looks like there is already
> another header that can appear multiple times.  I have never used it, but the
> 'Warning' header is part of the RFC and can appear multiple times.
>
> By abstracting the interface to not be specific to Set-Cookie headers, we are
> ready for the future where http 1.2 may add additional headers that can be
> repeated.  We can be very clear in the docs that the header_add function is only
> useful for Cookies at this time, and header_set should be used for all other
> headers.

These are good concerns. My concern is about proliferation of the C::A
interface. If we have "header_add", but /not/ add_cookie, I could be
happy.

header_add() can be documented to explain It's really only useful for
cookies and warnings right now. 

>> Finally, I'll mention the solution that doesn't involve any code
>> changes: You can accumulate your headers in your own data structure, and
>> pass that to header_props() once at the end.
>
> That is what I do now, and is the main reason why I want the functionality in
> CGI::App :)  That method doesn't allow for releasing reusable CGI::App modules
> on CPAN, since everyone would have to follow these internal data-structures. 
> Hence I think there is a good case for including it in the core CGI::App API.

I agree. Having this in CGI::App will make our apps more consistent and
make them easy to re-use and share.

	Mark

-- 
http://mark.stosberg.com/ 


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed