.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{
.    if \nF \{
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "DBD::Gofer 3"
.TH DBD::Gofer 3 "2014-02-05" "perl v5.16.3" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
DBD::Gofer \- A stateless\-proxy driver for communicating with a remote DBI
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 1
\&  use DBI;
\&
\&  $original_dsn = "dbi:..."; # your original DBI Data Source Name
\&
\&  $dbh = DBI\->connect("dbi:Gofer:transport=$transport;...;dsn=$original_dsn",
\&                      $user, $passwd, \e%attributes);
\&
\&  ... use $dbh as if it was connected to $original_dsn ...
.Ve
.PP
The \f(CW\*(C`transport=$transport\*(C'\fR part specifies the name of the module to use to
transport the requests to the remote \s-1DBI.\s0 If \f(CW$transport\fR doesn't contain any
double colons then it's prefixed with \f(CW\*(C`DBD::Gofer::Transport::\*(C'\fR.
.PP
The \f(CW\*(C`dsn=$original_dsn\*(C'\fR part \fImust be the last element\fR of the \s-1DSN\s0 because
everything after \f(CW\*(C`dsn=\*(C'\fR is assumed to be the \s-1DSN\s0 that the remote \s-1DBI\s0 should
use.
.PP
The \f(CW\*(C`...\*(C'\fR represents attributes that influence the operation of the Gofer
driver or transport. These are described below or in the documentation of the
transport module being used.
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
DBD::Gofer is a \s-1DBI\s0 database driver that forwards requests to another \s-1DBI\s0
driver, usually in a separate process, often on a separate machine. It tries to
be as transparent as possible so it appears that you are using the remote
driver directly.
.PP
DBD::Gofer is very similar to DBD::Proxy. The major difference is that with
DBD::Gofer no state is maintained on the remote end. That means every
request contains all the information needed to create the required state. (So,
for example, every request includes the \s-1DSN\s0 to connect to.) Each request can be
sent to any available server. The server executes the request and returns a
single response that includes all the data.
.PP
This is very similar to the way http works as a stateless protocol for the web.
Each request from your web browser can be handled by a different web server process.
.SS "Use Cases"
.IX Subsection "Use Cases"
This may seem like pointless overhead but there are situations where this is a
very good thing. Let's consider a specific case.
.PP
Imagine using DBD::Gofer with an http transport. Your application calls
\&\fIconnect()\fR, prepare(\*(L"select * from table where foo=?\*(R"), \fIbind_param()\fR, and \fIexecute()\fR.
At this point DBD::Gofer builds a request containing all the information
about the method calls. It then uses the httpd transport to send that request
to an apache web server.
.PP
This 'dbi execute' web server executes the request (using DBI::Gofer::Execute
and related modules) and builds a response that contains all the rows of data,
if the statement returned any, along with all the attributes that describe the
results, such as \f(CW$sth\fR\->{\s-1NAME\s0}. This response is sent back to DBD::Gofer which
unpacks it and presents it to the application as if it had executed the
statement itself.
.SS "Advantages"
.IX Subsection "Advantages"
Okay, but you still don't see the point? Well let's consider what we've gained:
.PP
\fIConnection Pooling and Throttling\fR
.IX Subsection "Connection Pooling and Throttling"
.PP
The 'dbi execute' web server leverages all the functionality of web
infrastructure in terms of load balancing, high-availability, firewalls, access
management, proxying, caching.
.PP
At its most basic level you get a configurable pool of persistent database connections.
.PP
\fISimple Scaling\fR
.IX Subsection "Simple Scaling"
.PP
Got thousands of processes all trying to connect to the database? You can use
DBD::Gofer to connect them to your smaller pool of 'dbi execute' web servers instead.
.PP
\fICaching\fR
.IX Subsection "Caching"
.PP
Client-side caching is as simple as adding "\f(CW\*(C`cache=1\*(C'\fR" to the \s-1DSN.\s0
This feature alone can be worth using DBD::Gofer for.
.PP
\fIFewer Network Round-trips\fR
.IX Subsection "Fewer Network Round-trips"
.PP
DBD::Gofer sends as few requests as possible (dependent on the policy being used).
.PP
\fIThin Clients / Unsupported Platforms\fR
.IX Subsection "Thin Clients / Unsupported Platforms"
.PP
You no longer need drivers for your database on every system.  DBD::Gofer is pure perl.
.SH "CONSTRAINTS"
.IX Header "CONSTRAINTS"
There are some natural constraints imposed by the DBD::Gofer 'stateless' approach.
But not many:
.SS "You can't change database handle attributes after \fIconnect()\fP"
.IX Subsection "You can't change database handle attributes after connect()"
You can't change database handle attributes after you've connected.
Use the \fIconnect()\fR call to specify all the attribute settings you want.
.PP
This is because it's critical that when a request is complete the database
handle is left in the same state it was when first connected.
.PP
An exception is made for attributes with names starting "\f(CW\*(C`private_\*(C'\fR":
They can be set after \fIconnect()\fR but the change is only applied locally.
.SS "You can't change statement handle attributes after \fIprepare()\fP"
.IX Subsection "You can't change statement handle attributes after prepare()"
You can't change statement handle attributes after prepare.
.PP
An exception is made for attributes with names starting "\f(CW\*(C`private_\*(C'\fR":
They can be set after \fIprepare()\fR but the change is only applied locally.
.SS "You can't use transactions"
.IX Subsection "You can't use transactions"
AutoCommit only. Transactions aren't supported.
.PP
(In theory transactions could be supported when using a transport that
maintains a connection, like \f(CW\*(C`stream\*(C'\fR does. If you're interested in this
please get in touch via dbi\-dev@perl.org)
.SS "You can't call driver-private sth methods"
.IX Subsection "You can't call driver-private sth methods"
But that's rarely needed anyway.
.SH "GENERAL CAVEATS"
.IX Header "GENERAL CAVEATS"
A few important things to keep in mind when using DBD::Gofer:
.SS "Temporary tables, locks, and other per-connection persistent state"
.IX Subsection "Temporary tables, locks, and other per-connection persistent state"
You shouldn't expect any per-session state to persist between requests.
This includes locks and temporary tables.
.PP
Because the server-side may execute your requests via a different
database connections, you can't rely on any per-connection persistent state,
such as temporary tables, being available from one request to the next.
.PP
This is an easy trap to fall into. A good way to check for this is to test your
code with a Gofer policy package that sets the \f(CW\*(C`connect_method\*(C'\fR policy to
\&'connect' to force a new connection for each request. The \f(CW\*(C`pedantic\*(C'\fR policy does this.
.SS "Driver-private Database Handle Attributes"
.IX Subsection "Driver-private Database Handle Attributes"
Some driver-private dbh attributes may not be available if the driver has not
implemented the \fIprivate_attribute_info()\fR method (added in \s-1DBI 1.54\s0).
.SS "Driver-private Statement Handle Attributes"
.IX Subsection "Driver-private Statement Handle Attributes"
Driver-private sth attributes can be set in the \fIprepare()\fR call. \s-1TODO\s0
.PP
Some driver-private sth attributes may not be available if the driver has not
implemented the \fIprivate_attribute_info()\fR method (added in \s-1DBI 1.54\s0).
.SS "Multiple Resultsets"
.IX Subsection "Multiple Resultsets"
Multiple resultsets are supported only if the driver supports the \fImore_results()\fR method
(an exception is made for DBD::Sybase).
.SS "Statement activity that also updates dbh attributes"
.IX Subsection "Statement activity that also updates dbh attributes"
Some drivers may update one or more dbh attributes after performing activity on
a child sth.  For example, DBD::mysql provides \f(CW$dbh\fR\->{mysql_insertid} in addition to
\&\f(CW$sth\fR\->{mysql_insertid}. Currently mysql_insertid is supported via a hack but a
more general mechanism is needed for other drivers to use.
.SS "Methods that report an error always return undef"
.IX Subsection "Methods that report an error always return undef"
With DBD::Gofer, a method that sets an error always return an undef or empty list.
That shouldn't be a problem in practice because the \s-1DBI\s0 doesn't define any
methods that return meaningful values while also reporting an error.
.SS "Subclassing only applies to client-side"
.IX Subsection "Subclassing only applies to client-side"
The RootClass and DbTypeSubclass attributes are not passed to the Gofer server.
.SH "CAVEATS FOR SPECIFIC METHODS"
.IX Header "CAVEATS FOR SPECIFIC METHODS"
.SS "last_insert_id"
.IX Subsection "last_insert_id"
To enable use of last_insert_id you need to indicate to DBD::Gofer that you'd
like to use it.  You do that my adding a \f(CW\*(C`go_last_insert_id_args\*(C'\fR attribute to
the \fIdo()\fR or \fIprepare()\fR method calls. For example:
.PP
.Vb 1
\&    $dbh\->do($sql, { go_last_insert_id_args => [...] });
.Ve
.PP
or
.PP
.Vb 1
\&    $sth = $dbh\->prepare($sql, { go_last_insert_id_args => [...] });
.Ve
.PP
The array reference should contains the args that you want passed to the
\&\fIlast_insert_id()\fR method.
.SS "execute_for_fetch"
.IX Subsection "execute_for_fetch"
The array methods \fIbind_param_array()\fR and \fIexecute_array()\fR are supported.
When \fIexecute_array()\fR is called the data is serialized and executed in a single
round-trip to the Gofer server. This makes it very fast, but requires enough
memory to store all the serialized data.
.PP
The \fIexecute_for_fetch()\fR method currently isn't optimised, it uses the \s-1DBI\s0
fallback behaviour of executing each tuple individually.
(It could be implemented as a wrapper for \fIexecute_array()\fR \- patches welcome.)
.SH "TRANSPORTS"
.IX Header "TRANSPORTS"
DBD::Gofer doesn't concern itself with transporting requests and responses to and fro.
For that it uses special Gofer transport modules.
.PP
Gofer transport modules usually come in pairs: one for the 'client' DBD::Gofer
driver to use and one for the remote 'server' end. They have very similar names:
.PP
.Vb 2
\&    DBD::Gofer::Transport::<foo>
\&    DBI::Gofer::Transport::<foo>
.Ve
.PP
Sometimes the transports on the \s-1DBD\s0 and \s-1DBI\s0 sides may have different names. For
example DBD::Gofer::Transport::http is typically used with DBI::Gofer::Transport::mod_perl
(DBD::Gofer::Transport::http and DBI::Gofer::Transport::mod_perl modules are
part of the GoferTransport-http distribution).
.SS "Bundled Transports"
.IX Subsection "Bundled Transports"
Several transport modules are provided with DBD::Gofer:
.PP
\fInull\fR
.IX Subsection "null"
.PP
The null transport is the simplest of them all. It doesn't actually transport the request anywhere.
It just serializes (freezes) the request into a string, then thaws it back into
a data structure before passing it to DBI::Gofer::Execute to execute. The same
freeze and thaw is applied to the results.
.PP
The null transport is the best way to test if your application will work with Gofer.
Just set the \s-1DBI_AUTOPROXY\s0 environment variable to "\f(CW\*(C`dbi:Gofer:transport=null;policy=pedantic\*(C'\fR"
(see \*(L"Using \s-1DBI_AUTOPROXY\*(R"\s0 below) and run your application, or ideally its test suite, as usual.
.PP
It doesn't take any parameters.
.PP
\fIpipeone\fR
.IX Subsection "pipeone"
.PP
The pipeone transport launches a subprocess for each request. It passes in the
request and reads the response.
.PP
The fact that a new subprocess is started for each request ensures that the
server side is truly stateless. While this does make the transport \fIvery\fR slow,
it is useful as a way to test that your application doesn't depend on
per-connection state, such as temporary tables, persisting between requests.
.PP
It's also useful both as a proof of concept and as a base class for the stream
driver.
.PP
\fIstream\fR
.IX Subsection "stream"
.PP
The stream driver also launches a subprocess and writes requests and reads
responses, like the pipeone transport.  In this case, however, the subprocess
is expected to handle more that one request. (Though it will be automatically
restarted if it exits.)
.PP
This is the first transport that is truly useful because it can launch the
subprocess on a remote machine using \f(CW\*(C`ssh\*(C'\fR. This means you can now use DBD::Gofer
to easily access any databases that's accessible from any system you can login to.
You also get all the benefits of ssh, including encryption and optional compression.
.PP
See \*(L"Using \s-1DBI_AUTOPROXY\*(R"\s0 below for an example.
.SS "Other Transports"
.IX Subsection "Other Transports"
Implementing a Gofer transport is \fIvery\fR simple, and more transports are very welcome.
Just take a look at any existing transports that are similar to your needs.
.PP
\fIhttp\fR
.IX Subsection "http"
.PP
See the GoferTransport-http distribution on \s-1CPAN:\s0 http://search.cpan.org/dist/GoferTransport\-http/
.PP
\fIGearman\fR
.IX Subsection "Gearman"
.PP
I know Ask Bjørn Hansen has implemented a transport for the \f(CW\*(C`gearman\*(C'\fR distributed
job system, though it's not on \s-1CPAN\s0 at the time of writing this.
.SH "CONNECTING"
.IX Header "CONNECTING"
Simply prefix your existing \s-1DSN\s0 with "\f(CW\*(C`dbi:Gofer:transport=$transport;dsn=\*(C'\fR"
where \f(CW$transport\fR is the name of the Gofer transport you want to use (see \*(L"\s-1TRANSPORTS\*(R"\s0).
The \f(CW\*(C`transport\*(C'\fR and \f(CW\*(C`dsn\*(C'\fR attributes must be specified and the \f(CW\*(C`dsn\*(C'\fR attributes must be last.
.PP
Other attributes can be specified in the \s-1DSN\s0 to configure DBD::Gofer and/or the
Gofer transport module being used. The main attributes after \f(CW\*(C`transport\*(C'\fR, are
\&\f(CW\*(C`url\*(C'\fR and \f(CW\*(C`policy\*(C'\fR. These and other attributes are described below.
.SS "Using \s-1DBI_AUTOPROXY\s0"
.IX Subsection "Using DBI_AUTOPROXY"
The simplest way to try out DBD::Gofer is to set the \s-1DBI_AUTOPROXY\s0 environment variable.
In this case you don't include the \f(CW\*(C`dsn=\*(C'\fR part. For example:
.PP
.Vb 1
\&    export DBI_AUTOPROXY="dbi:Gofer:transport=null"
.Ve
.PP
or, for a more useful example, try:
.PP
.Vb 1
\&    export DBI_AUTOPROXY="dbi:Gofer:transport=stream;url=ssh:user@example.com"
.Ve
.SS "Connection Attributes"
.IX Subsection "Connection Attributes"
These attributes can be specified in the \s-1DSN.\s0 They can also be passed in the
\&\e%attr parameter of the \s-1DBI\s0 connect method by adding a "\f(CW\*(C`go_\*(C'\fR" prefix to the name.
.PP
\fItransport\fR
.IX Subsection "transport"
.PP
Specifies the Gofer transport class to use. Required. See \*(L"\s-1TRANSPORTS\*(R"\s0 above.
.PP
If the value does not include \f(CW\*(C`::\*(C'\fR then "\f(CW\*(C`DBD::Gofer::Transport::\*(C'\fR" is prefixed.
.PP
The transport object can be accessed via \f(CW$h\fR\->{go_transport}.
.PP
\fIdsn\fR
.IX Subsection "dsn"
.PP
Specifies the \s-1DSN\s0 for the remote side to connect to. Required, and must be last.
.PP
\fIurl\fR
.IX Subsection "url"
.PP
Used to tell the transport where to connect to. The exact form of the value depends on the transport used.
.PP
\fIpolicy\fR
.IX Subsection "policy"
.PP
Specifies the policy to use. See \*(L"\s-1CONFIGURING BEHAVIOUR POLICY\*(R"\s0.
.PP
If the value does not include \f(CW\*(C`::\*(C'\fR then "\f(CW\*(C`DBD::Gofer::Policy\*(C'\fR" is prefixed.
.PP
The policy object can be accessed via \f(CW$h\fR\->{go_policy}.
.PP
\fItimeout\fR
.IX Subsection "timeout"
.PP
Specifies a timeout, in seconds, to use when waiting for responses from the server side.
.PP
\fIretry_limit\fR
.IX Subsection "retry_limit"
.PP
Specifies the number of times a failed request will be retried. Default is 0.
.PP
\fIretry_hook\fR
.IX Subsection "retry_hook"
.PP
Specifies a code reference to be called to decide if a failed request should be retried.
The code reference is called like this:
.PP
.Vb 2
\&  $transport = $h\->{go_transport};
\&  $retry = $transport\->go_retry_hook\->($request, $response, $transport);
.Ve
.PP
If it returns true then the request will be retried, up to the \f(CW\*(C`retry_limit\*(C'\fR.
If it returns a false but defined value then the request will not be retried.
If it returns undef then the default behaviour will be used, as if \f(CW\*(C`retry_hook\*(C'\fR
had not been specified.
.PP
The default behaviour is to retry requests where \f(CW$request\fR\->is_idempotent is true,
or the error message matches \f(CW\*(C`/induced by DBI_GOFER_RANDOM/\*(C'\fR.
.PP
\fIcache\fR
.IX Subsection "cache"
.PP
Specifies that client-side caching should be performed.  The value is the name
of a cache class to use.
.PP
Any class implementing get($key) and set($key, \f(CW$value\fR) methods can be used.
That includes a great many powerful caching classes on \s-1CPAN,\s0 including the
Cache and Cache::Cache distributions.
.PP
You can use "\f(CW\*(C`cache=1\*(C'\fR\*(L" is a shortcut for \*(R"\f(CW\*(C`cache=DBI::Util::CacheMemory\*(C'\fR".
See DBI::Util::CacheMemory for a description of this simple fast default cache.
.PP
The cache object can be accessed via \f(CW$h\fR\->go_cache. For example:
.PP
.Vb 1
\&    $dbh\->go_cache\->clear; # free up memory being used by the cache
.Ve
.PP
The cache keys are the frozen (serialized) requests, and the values are the
frozen responses.
.PP
The default behaviour is to only use the cache for requests where
\&\f(CW$request\fR\->is_idempotent is true (i.e., the dbh has the ReadOnly attribute set
or the \s-1SQL\s0 statement is obviously a \s-1SELECT\s0 without a \s-1FOR UPDATE\s0 clause.)
.PP
For even more control you can use the \f(CW\*(C`go_cache\*(C'\fR attribute to pass in an
instantiated cache object. Individual methods, including \fIprepare()\fR, can also
specify alternative caches via the \f(CW\*(C`go_cache\*(C'\fR attribute. For example, to
specify no caching for a particular query, you could use
.PP
.Vb 1
\&    $sth = $dbh\->prepare( $sql, { go_cache => 0 } );
.Ve
.PP
This can be used to implement different caching policies for different statements.
.PP
It's interesting to note that DBD::Gofer can be used to add client-side caching
to any (gofer compatible) application, with no code changes and no need for a
gofer server.  Just set the \s-1DBI_AUTOPROXY\s0 environment variable like this:
.PP
.Vb 1
\&    DBI_AUTOPROXY=\*(Aqdbi:Gofer:transport=null;cache=1\*(Aq
.Ve
.SH "CONFIGURING BEHAVIOUR POLICY"
.IX Header "CONFIGURING BEHAVIOUR POLICY"
DBD::Gofer supports a 'policy' mechanism that allows you to fine-tune the number of round-trips to the Gofer server.
The policies are grouped into classes (which may be subclassed) and referenced by the name of the class.
.PP
The DBD::Gofer::Policy::Base class is the base class for all the policy
packages and describes all the available policies.
.PP
Three policy packages are supplied with DBD::Gofer:
.PP
DBD::Gofer::Policy::pedantic is most 'transparent' but slowest because it
makes more  round-trips to the Gofer server.
.PP
DBD::Gofer::Policy::classic is a reasonable compromise \- it's the default policy.
.PP
DBD::Gofer::Policy::rush is fastest, but may require code changes in your applications.
.PP
Generally the default \f(CW\*(C`classic\*(C'\fR policy is fine. When first testing an existing
application with Gofer it is a good idea to start with the \f(CW\*(C`pedantic\*(C'\fR policy
first and then switch to \f(CW\*(C`classic\*(C'\fR or a custom policy, for final testing.
.SH "AUTHOR"
.IX Header "AUTHOR"
Tim Bunce, <http://www.tim.bunce.name>
.SH "LICENCE AND COPYRIGHT"
.IX Header "LICENCE AND COPYRIGHT"
Copyright (c) 2007, Tim Bunce, Ireland. All rights reserved.
.PP
This module is free software; you can redistribute it and/or
modify it under the same terms as Perl itself. See perlartistic.
.SH "ACKNOWLEDGEMENTS"
.IX Header "ACKNOWLEDGEMENTS"
The development of DBD::Gofer and related modules was sponsored by
Shopzilla.com (<http://Shopzilla.com>), where I currently work.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
DBI::Gofer::Request, DBI::Gofer::Response, DBI::Gofer::Execute.
.PP
DBI::Gofer::Transport::Base, DBD::Gofer::Policy::Base.
.PP
\&\s-1DBI\s0
.SH "Caveats for specific drivers"
.IX Header "Caveats for specific drivers"
This section aims to record issues to be aware of when using Gofer with specific drivers.
It usually only documents issues that are not natural consequences of the limitations
of the Gofer approach \- as documented above.
.SH "TODO"
.IX Header "TODO"
This is just a random brain dump... (There's more in the source of the Changes file, not the pod)
.PP
Document policy mechanism
.PP
Add mechanism for transports to list config params and for Gofer to apply any that match (and warn if any left over?)
.PP
Driver-private sth attributes \- set via \fIprepare()\fR \- change \s-1DBI\s0 spec
.PP
add hooks into transport base class for checking & updating a result set cache
   ie via a standard cache interface such as:
   http://search.cpan.org/~robm/Cache\-FastMmap/FastMmap.pm
   http://search.cpan.org/~bradfitz/Cache\-Memcached/lib/Cache/Memcached.pm
   http://search.cpan.org/~dclinton/Cache\-Cache/
   http://search.cpan.org/~cleishman/Cache/
Also caching instructions could be passed through the httpd transport layer
in such a way that appropriate http cache headers are added to the results
so that web caches (squid etc) could be used to implement the caching.
(\s-1MUST\s0 require the use of \s-1GET\s0 rather than \s-1POST\s0 requests.)
.PP
Rework handling of installed_methods to not piggyback on dbh_attributes?
.PP
Perhaps support transactions for transports where it's possible (ie null and stream)?
Would make stream transport (ie ssh) more useful to more people.
.PP
Make sth_result_attr more like dbh_attributes (using '*' etc)
.PP
Add \f(CW@val\fR = FETCH_many(@names) to \s-1DBI\s0 in C and use in Gofer/Execute?
.PP
Implement _new_sth in C.