Tim Bunce wrote:
>
> On Thu, Nov 16, 2000 at 10:03:11AM -0800, Jeff Zucker wrote:
> > Tim Bunce wrote:
> > >
> > > On Wed, Nov 15, 2000 at 10:38:09AM -0800, Jeff Zucker wrote:
> > >>
> > >> The namespace would look like this:
> > >>
> > >> DBD/AnyData.pm DBI access to in-memory & file-based data
> > >> AnyData.pm access & convert many data formats
> > >> AnyData/Parser/CSV.pm parser for CSV (comma separated values)
> > >> AnyData/Parser/XML.pm parser for XML data & files
> > >> AnyData/Parser/Ini.pm parser for Ini style config data & files
> > >> AnyData/Parser/FixedWidth.pm parser for fixed-width records
> > >> AnyData/Parser/*.pm parsers for other data formats
> > >> AnyData/Storage/RAM.pm storage manager for in-memory tables
> > >> AnyData/Storage/File.pm storage manager for file-based tables
> > >> AnyData/Storage/Tie.pm storage manager for tied structures
> > >> AnyData/Storage/*.pm other types of storage managers
> > >
>
> So perhaps AnyData/Record/*.pm would be more descriptive of their role.
I could certainly live with that if you think it best.
My hesitations are a) some data formats will possibly need to be parsed
a table at a time, rather than a record at a time; b) some data accessed
via the non-DBI portion will consist of single hash of key-values (e.g.
a simple config file) so the concept of "record" is a bit misleading; c)
the non-DBI portion also provides methods to create, convert, or access
strings which might be done totally out of a "table/record" context; d)
"Parser" is parallel to "Storage" whereas "Record" is not.
Perhaps AnyData/Format/*.pm? (Although the use of "format" as a verb
would be less descriptive of its role than its use as a noun). Or
AnyData/DataParser/*.pm to distinguish them from SQL parsers?
--
Jeff
