Re: FF:: namespace (was: New module: FLV file parsing)

# from David Landgren
# on Friday 02 December 2005 08:25 am:

>In about 10 days time, I'm going to forget utterly that FF means File
>Formats. Does it need to be so terse?

Considering the number of file formats which currently have toplevel 
names, FF:: isn't that terse.  Besides, search results should mean that 
you _don't have to remember_ what FF means.

SVG
HTML
XML
PostScript (yeah, I know, let's pretend it's a "format")
PDF
Pdf (heh)
CSV
POD
ABI
CSS
GFL
VRML
YAML

File::Format::RIFF is of course misplaced if you consider what other 
File:: modules do (typically fs queries/manipulation) and what 
File::Format might do given the use of formats in printf (and/or what 
the dos "format" command does :-)

Then there is the issue of tucking them away under whatever toplevel 
namespace holds the domain with which that file format is associated 
such as

Geo::GDAL
Text::xSV
Graphics::MNG
Image::PNGwriter
Apache::ConfigFile

In some of these cases, putting the module under a namespace of related 
tools makes sense, but the problem is that the above two models are the 
only thing that new authors have as examples.  Either you blaze a trail 
to a new TLNS or hide under an existing <mumble> (which may or may not 
be completely unrelated to the file format.)

>Tossing out another suggestion with this in mind: Parse::File::FLV

But then we end up with Write::File::FLV ?  Consider a distribution 
which reads and writes a given binary format (I'll call it GBF.)

You want a parser, a writer, maybe a DOM, and/or a bit juggler, and 
you'll definitely need some constants and of course someone will 
eventually come along and write a ::Simple version.  If we're going to 
use Parse::, then I'll assume that writers live in Write:: (since 
parsers are parsers, right?)

Parse::File::GBF - Front end to GBF read/write interface
Parse::File::GBF::Parser
Parse::File::GBF::Bytes
Parse::File::GBF::DOM
Parse::File::GBF::Constants
Parse::File::GBF::Simple
Write::File::GBF - just a directory under this model
Write::File::GBF::Simple
Write::File::GBF::Stream

But notice that Write::File::GBF probably requires 
Parse::File::GBF::Constants, etc.  It's rather unsettling.

Now consider the more comprehensible, discoverable single tree under 
FF::

FF::GBF - Front end to GBF read/write interface
FF::GBF::Parser
FF::GBF::Bytes
FF::GBF::DOM
FF::GBF::Constants
FF::GBF::Writer
FF::GBF::Simple
FF::GBF::Writer::Stream

Does that sound better?

--Eric
-- 
"It is impossible to make anything foolproof because fools are so 
ingenious."
--Murphy's Second Corollary
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------