Bioperl: Whither DBD::RAM? (Was Re: [ANNOUNCE] corrected version 0.072 of DBD::RAM) (fwd)

[David Block]

This is an interesting development that I thought the community should be
made aware of.  Perlish SQL access to arbitrary data formats?  Hmmm...

-Dave

---------- Forwarded message ----------
Date: Fri, 26 May 2000 10:14:37 -0700
From: Jeff Zucker <jeff@vpservices.com>
To: dbi-users <dbi-users@isc.org>, dbi-dev@isc.org
Subject: Whither DBD::RAM? (Was Re: [ANNOUNCE] corrected version 0.072 of 
    DBD::RAM)

Tim Bunce wrote:
> 
> On Thu, May 25, 2000 at 01:14:49PM -0700, Jeff Zucker wrote:
> >
> > Your guess is a good one, or at least it was for the first version of
> > this module.  It started out as exactly that -- an interface to
> > in-memory databases.  But I have extended it to include many kinds of
> > file accessing which can be use instead of or in addition to its
> > in-memory features.
> 
> It may be time for a new name. I'll kick off the running with...
> 
>         DBD::Handy

:-) :-) :-)  

And many LOLs for all the great names.  My daughter's favorites are the
Kitchen Sink one and Ginzu.

I think I'll go with DBD::zen -- nothing is a database and everything is
database.

I want to just say up front that this is all living proof of the power
of modularization and base classes and the collaborative nature of open
source.  I've pretty much just built stuff on top of Jochen Wiedman's
DBD::File and SQL::Statement.  He designed those to be base classes for
other development and I just took the ball and ran with it.  Thanks
Jochen!  Although it goes without saying, all of that applies
triple-time to DBI itself.  Thanks Tim and Alligator and everyone on the
dbi lists!  Hey, and while I'm at it, thanks Larry and Randal and Damian
and Gisle and Clark and Lincoln and all the porters and pumpkings (sic)!

I'll ask more later about future plans but one idea I want to toss into
the ring now is that I'm already working on extending the user-defined
feature so that one can pass in not only  a "read_sub" and a delimiter
pattern (both available now), but also a "write_sub" (coming soon). I'd
then make a simple API to describe how to write those and make a
mecahnism for reading those from files.  This would make the module a
mini-dbi-within-the-dbi and authors could write *very* simple drivers
that would plug into this module to treat flat file or data format foo,
or binary file header format bar, or directory sytem baz (I am already
planning SELECT file FROM drive WHERE path IN (?,?,?) AND name LIKE ?
AND date > ? AND contents LIKE ?).

The authors of those plugins would essentially not need to know anything
about DBI or DBD, or even necessarily SQL, they would only need to
describe how to parse their chosen format. These plugin drivers could be
simple enough to write on the fly for once-only stuff (e.g for
conversions out of some god-awful unique legacy material) or for more
permanent common formats that could be distributed for general use. 
This would leverage future development of DBD::zen and SQL::Statement
and DBD::File so that, as they get more robust, all of the various
format parsers would also grow automagically.

If we go this route, maybe some of it belongs in DBI itself.  At least
that would save us from thinking of a name :-).

I'm open to any and all suggestions.

-- 
Jeff


------------------------------------------------------------------------------
DBI HOME PAGE AND ARCHIVES: http://www.symbolstone.org/technology/perl/DBI/
To unsubscribe from this list, please visit: http://www.isc.org/dbi-lists.html
If you are without web access, or if you are having trouble with the web page, 
please send mail to dbi-users-request@isc.org with the subject line of:
'unsubscribe'.
------------------------------------------------------------------------------ 

=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://bio.perl.org/
For info about how to (un)subscribe, where messages are archived, etc:
http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
====================================================================