httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram <>
Subject Re: Apache::Cookies vs CGI::Cookies
Date Fri, 22 Apr 2005 21:02:18 GMT
[ ... ]

> >> Actually I take that back.  In apreq2, string context calls value(),
> >> which is what I'd rather backport to apreq1 (instead of using as_string).
> >
> > Are you sure of that? I downloaded libapreq2-2.04_03-dev.tar.gz in it there
> > is a file called Cookie_pm (in glue/perl/xsbuilder/Apache/Cookie) which has
> > the following code:
> >
> > package Apache::Cookie;
> > use overload '""' => sub { shift->as_string };
> That's true for 2.04-dev, but it's not true for 2.05-dev.  I suppose
> that's another delta that I need to document somewhere.

Another option could be to decide what function to call on a per-object base, by
passing a certain value to the constructor (for example)...
but then ofcourse there is the question what the default should be... if migrating
from CGI::Cookie to Apache::Cookie/Apache2::Cookie should be as easy as possible
then as_string should be the default...

> The difference boils down to this: is our Cookie API request-oriented
> or response-oriented?  Overloading with as_string() just makes it easy
> to send outgoing cookies, when really this project is about parsing incoming
> ones.

That's true for the C-API, but it is true for the Perl-API aswell? when one sees
the name apache-request, one can easily figures that it is about parsing, but not
when the only visible name is Apache::Cookie (except ofcourse at installation time,
which is something different)

> I'm seriously considering removing bake() and bake2() from the C API,
> because that way I could also remove headers_out from the apreq_module API.
> We'd still keep them as perl subs for Apache2::Cookie, but they just
> wouldn't be portable to APR::Request::CGI anymore.  Any opinions?

That would be fine by me.


View raw message