|
From: Jeff Z. <je...@vp...> - 2000-09-07 17:01:17
|
Tim Bunce wrote:
>
> [snip recap of opening DBD::RAM for other authors to write plug-in parsers
> and storage managers and renaming it to either AnyData or PerlDB]
>
> I like it. I think I'd prefer 'AnyData' over 'PerlDB' (and anyway, isn't
> PerlDB the name of a seperate project?)
The suggestion to use the PerlDB name came from Andy Duncan and I'm
neutral on it. He based the suggestion on the fact that the PerlDB
project is currently inactive and having something specific to work with
will hopefully spark some activity and on the idea that the way I am
opening up AnyData for other authors to create a variety of data parsers
and a variety of storage managers can be extended to this kind of
broader framework:
DBD::PerlDB --+-- various Data parsers ----- PerlDB::Parser::*.pm
(1)
|
+-- various Storage managers -- PerlDB::Storage::*.pm
(2)
|
+-- various SQL parsers ------- PerlDB::SQLparse::*.pm
(3)
|
+-- various SQL executors ----- PerlDB::SQLexec:: *.pm
(4)
A version of #1 and #2 will be part of the coming AnyData release and
versions of #3,#4 will be part of it as soon as I (or others who join
the project) have time to get back to my re-write of SQL::Statement in
Parse::RecDescent/Parse::Yapp.
I *do* know that the kinds of parsers and storage managers I am using in
RAM/AnyData are basically toys compared to what will be needed for the
final PerlDB and that the key will be defining the API that plugs those
submodules into the main DBD. But it seems that what I have going so
far could be a springboard into that and it also seems that it would be
nice for the final PerlDB to cover a wide range of pure-Perl database
options including the simple file-based things I am working on as well
as more sophisticated things like direct Berkeley_DB access.
In either case, my interest is in seeing the PerlDB succeed as a group
effort so I'll go with whatever naming convention works best to meet
that goal.
<regis>Your final answers?</regis>
--
Jeff
|