Point taken, mostly... However, I'd say that even something so nebulous as a framework should have some concise description. If it doesn't, it probably should be either broken up or put out of its misery. The name "Apache" is necessary because an "httpd" is a common, well-established chunk of software with many implementations. There's no particular feature that distinguishes Apache within its niche; while it may be better than IIS, there's no concise description of how. Therefore Apache has to be distinguished based on a label or brand.
Given Apache's brand recognition, it's not such a bad name, but if it were distributed through CPAN, it should be called "HTTP::Apache" or "HTTP::Server::Apache" or something. In some sense, CPAN's naming works because it puts function before brand, making it easy to find software to solve particular problems affecting small numbers of people, and to distribute solutions to such idiosyncratic problems. If CPAN becomes more and more about reinventing subtly-different wheels, then tags or "brands" will be required, but for it to continue to work, these should always be subordinate to the functional labels.
Personally, I'd much rather see people working to improve existing modules and solve new problems than write endless config- and argument-parsing modules, web application frameworks, or what have you. I understand the appeal, but at some point your alternate approach won't be different, better, or cleaner, but merely "other". People will choose your module for the same superficial, brand-identification reasons they choose Crest over Colgate. Your module's needing a vanity tag suggests (but doesn't necessarily entail) that you may be in this situation.
/s
PS: Looking for something to adopt? Identify the 3-4 ordered collection (heap) modules on CPAN, choose the one that sucks least, and give it a beautiful, natural tied array interface and a screaming XS backend. | [reply] |
