pardon my ignorance on the matter, but wouldn't a pure-perl DBI make it easier (possible?) to compile scripts using the dbi to stand-alone executables? even though it would be nice if every maychine had perl installed, but the possibility of _easily_ deploying stand-alone programs for all those OSes might be very good for perl. i know that perlcc, etc. are terribly experimental, but that might change someday...(perl6?)
my context is that i want to deploy some perl-software, but don't want to have to care about what machine the customer has, whether he has perl installed, etc. he's not supposed to program, he's supposed to _use_ the program and not care about all the techie-stuff. dunno whether i'm making sense, M. > -----Original Message----- > From: Tim Bunce [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 22, 2002 10:10 AM > To: Troy Sniff > Cc: [EMAIL PROTECTED] > Subject: Pure-perl DBI emulation - what use? > > > I'd appreciate it if anyone who may be interested in a > pure-perl DBI emulation could explain why. Just so I can get > some idea of the real-world issues that a pure-perl DBI > emulation might address. > > I'd also like to know if those real-world issues could be > better addressed by bundling the DBI with perl, so if you > have perl installed anywhere then you'll also have the DBI > installed there. > > Tim. > > > On Fri, Mar 22, 2002 at 08:05:59AM -0700, Troy Sniff wrote: > > I'd like to get a copy of the DBI::Lite to look at. > > > > I might have a project that would be perfect for it. > > > > Troy > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > > > > I'd like to see a copy too. Sounds quite a bit like a > workaround I > > > was tooling around with in my head. Thanks. > > > > > > _________________________________________ > > > > > > From: Jeff Zucker <[EMAIL PROTECTED]> > > > Date: Thursday, March 21, 2002 > > > Time: 2:45:41 PM > > > Subject: Use Lib > > > > > > Bart Lateur wrote: > > > > > > > > On Wed, 20 Mar 2002 18:16:39 -0500, [EMAIL PROTECTED] wrote: > > > > > > > > >DBI is just being untarred and put in the modules dir. > No make > > > > >or anything like that. It's for a program that will run on > > > > >Linux/Unix/Windows and I don't want to have to require the > > > > >compiling or installation of DBI with the program. > > > > > > > > > >It may be hopeless... > > > > > > > > It is. > > > > > > > > You might get by by precompiling the module for each > > > platform you want > > > > to support, tar up that tree, and distribute that. Pretty > > > much like how > > > > modules for Windows get distributed... > > > > > > I hesitate to suggest this. TIM, please tell me if this > is too evil > > > to see the light of day: > > > > > > I have a module which might be called DBI::Lite (or ... > > > DBI::Emulation or AnyData::DBI::Lite or ?) which provides a DBI > > > emulation in pure perl. Basically, you'd need DBD::AnyData, > > > SQL::Statement, and DBI::Lite (all pure perl, no compilation > > > required) and you could use > > > do(),prepare(),execute(),fetch() and a few other features > including > > > placeholders. The module would work exactly like DBD:AnyData and > > > very similarly to DBD::CSV but would not require installation of > > > DBI. Once DBI is installed, the scripts would operate > identically > > > with a change of "use DBI::Lite;" to "use DBI;". Most > users would > > > be better off going straight to real DBI but in a case > like Nick's > > > it would save making compiled versions for multiple platforms. > > > > > > So, Tim, which namespace, or shall I keep it in the Dev::Null > > > namespace? > > > :-) > > > > > > -- > > > Jeff > > > > > > > > >
