On Wed, Aug 20, 2003 at 11:52:24AM -0400, Kurt Starsinic wrote: > On Aug 13, Mark Overmeer wrote: > > * Kurt Starsinic ([EMAIL PROTECTED]) [030813 15:30]: > > > On Aug 13, Perl Authors Upload Server wrote: > > > > The following module was proposed for inclusion in the Module List: > > > > > > > > modid: Mail::Box::Procmail > > > > Mail::Box::Procmail is a set of scripts and some classes which > > > > create procmail-like facilities. I already many modules in the > > > > Mail::Box::* namespace, but this one would be released as separate > > > > distribution. > > > > > > > > The main difference with the usual procmail implementations is that > > > > you do not need to create a cryptic configuration file with its own > > > > syntax (and therefore limitations), but you simply extend your own > > > > program based on Mail::Box and User::Identity. > > > > > > I don't think it's a good idea to write something that works > > > somewhat similarly to procmail, and calling it Mail::Box::Procmail. > > > Maybe Mail::Box::Process? > > > > "Procmail" as part of the name is to indicate the very comparible > > application. I have plans to support procmailrc files as well, probably > > using Mail::Procmailrc. Then it simply is procmail++ > > > > By using this name, I hope to attract more people into reading where this > > module is all about. > > > > > Also, does this operate on a mailbox (very much unlike procmail), > > > or on incoming messages? If the latter, then ::Box probably doesn't > > > belong in the name. > > > > There is already a Mail::Procmail (from Johan Vromans) which is a > > procmail implementation as usual. Besides, the "Mail::Box" in the > > name is to explicitly state that it uses the Mail::Box library. > > That's exactly what you don't want to do (IMHO). The module name > should indicate the functionality, not the implementation. As a > potential user, why should I care that your module uses Mail::Box? > If you re-implemented the internals in a future release, would you > rename the module? As a user, should I care?
Since Mail::Box is actually a large framework of modules it may be relevant in this case. But I agree that *::Procmail isn't a good name for a module that's just "like" procmail without explicit support for "being" procmail. Once that's added, even if only minimal, it would be okay but right now it's not good (and planning to do it doesn't really count). But, having said that, the Mail::Procmail is only "like" procmail and doesn't read procmail files so perhaps a precedent has been set: We could view the term "procmail" as a generic term for "content driven rule based email processing". Tim.
