FWIW, RC7 compiles fine on my MacBook Pro 10.4.8 with default Perl.
Not surprising.
Anyway, I wanted to discuss the Gofer http transport, where it
relates to caching.
In order to add seamless integration of a caching engine (squid,
Redline accelerator, etc...), there are some issues.
First, POST requests are never cached by Squid, and probably not by
most other engines. POST is generally a "write", so no accelerator
likes caching them. I suggest that the http transport take that into
account, and allow for passing a driver parameter with the statement
handle that specifies a POST or a GET (default should probably be
POST, it's safer, see below). The related DBI mod_perl transport
handler would only need a simple test of the method type to decide
how to extract the data.
Second, it would be nice to manage via the statement handle
parameters the http transport's headers. Some implementations might
allow a client to bypass a caching engine by setting the correct
headers.
So basically, I guess some kind of way to pass in transport
parameters via the sth should be codified. I see in the TODO section
"Driver-private sth attributes - set via prepare() - change DBI
spec", so that's probably what you were thinking.
There are ways around this if we're stuck without sth-based driver
parameters, by creating different read dbh's and write dbh's.
Technically that's probably the better way to go for a large scale
system, but I can see it confusing the smaller user.
Anyway, regarding GET and POST: POST is safer because it's guaranteed
to work, but it'll never be cached. GET works at least for a 2,048
character url, and potentially up to 8,000 characters, but you never
know what middleware device might truncate it. To compound the
problem, in order to be safe one would have to uri_encode_utf8() the
query string, which willl potentially bloat it even more.
So the question is... how big is a standard Gofer request package?
H
