Ok, so in the course of a project at work I've written a bunch of modules for reading and tracing mail logs. So far, I've only put a few of the base modules on CPAN as Mail::Log::Parse and friends.
Basic description of the ::Parse:: modules is that they parse the logs for you: The output is in a standard, defined, Perl data structure. They can read forwards and back at will, and handle compressed files transparently. (If you have IO::Uncompress::AnyUncompress.) Actual parsing is handled by format-specific subclasses, which can usually be written in one simple function. The work project is just about completed, so I've got a chance to step back and look at the modules, while I sanitize the test logs, document, and so forth for release. So, first thought: The name 'Mail::Log::Parse', which was basically picked quickly so I could get working, might not be the best. Particularly in creating a hierarchy, or living within the current hierarchy. On the other hand, there may be a better idea... The possible better idea is this: Instead of just trying to rename this, I could instead turn this into a general log parser framework. 99.9% of the code is completely generic already: It is, after all, only doing file-open, reading, caching, and seeking work. The mail-specific work is done in the subclasses. So, the two questions: First off, what do people think of me creating a general log parser framework based on this? Random or sequential access, compressed or uncompressed files. It can handle basically any log format (including mixed logs, where several programs are writing to the same file) as log as any line can be read as a line. Is this something needed/wanted/useful? Second, what should I call the module? If I'm re-purposing the code, I can change the name around entirely. If I'm not, is the current Mail::Log::Parse decent? Daniel T. Staal
