or, enable by setting the DBI_AUTOPROXY environment variable:
perl -MDBI::Gofer::Transport::stream -e run_stdio_hex
and feeds requests into it and reads responses from it. But that's not very useful.
With a "url=ssh:email@example.com" parameter it uses ssh to launch the subprocess on a remote system. That's much more useful!
It gives you secure remote access to DBI databases on any system you can login to. Using ssh also gives you optional compression and many other features (see the ssh manual for how to configure that and many other options via ~/.ssh/config file).
The actual command invoked is something like:
ssh -xq ssh:firstname.lastname@example.org bash -c $setup $run
where $run is the command shown above, and $command is
. .bash_profile 2>/dev/null || . .bash_login 2>/dev/null || . .profile 2>/dev/null; exec "$@"
which is trying (in a limited and fairly unportable way) to setup the environment (PATH, PERL5LIB etc) as it would be if you had logged in to that system.
The ""perl"" used in the command will default to the value of $^X when not using ssh. On most systems that's the full path to the perl that's currently executing.
Currently up to 5 different gofer stream connections (based on url) can persist. If more than 5 are in the cache when a new connection is made then the cache is cleared before adding the new connection. Simple but effective.
Automatically reconnect (within reason) if there's a transport error.
Decide on default for persistent connection - on or off? limits? ttl?
This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See perlartistic.