It has promise but needs someone to polish it up.
(I didn't write it and have barely looked at the code.)
Tim.
On Tue, Sep 19, 2000 at 12:50:57PM -0700, Tom Lancaster wrote:
> I know, seems promising, doesn't it, especially after the overview in
> the DBI book. On the other hand, you can do most
I know, seems promising, doesn't it, especially after the overview in
the DBI book. On the other hand, you can do most things another way -
SSH port forwarding for encrypted data transmission, straight DBI/DBD
available for most dbs, etc.
Bill McCabe wrote:
>
> That's a shame. I can see good us
That's a shame. I can see good use for it. Is it the RPC chunk that is slow
and unreliable or the DBI part? Or has no one really pursued making a
production-quality module out of it?
Bill
At 11:24 AM -0700 9/19/00, Tom Lancaster wrote:
>My experience of using DBI::Proxy several months ago is tha
My experience of using DBI::Proxy several months ago is that it's
terribly slow, and breaks all the time.
It's not meant to be used in a production environment ( and that's
according to the authors ).
I managed to get it running, on linux and NT, but due to the lack of a
working fork() or thread
Hi All
I'm thinking of restructuring my setup so that I have my apache/mod_perl
servers access database servers remotely using DBI::Proxy, rather than
locally. Does anyone have a sense of what kind of performance degradation I
should expect? Will it come chiefly from network latency (leaving
encr