On May 17, 2004 02:04 am, khemir nadim wrote: > I prefere technology sorted modules. The monster framework structures some > distributions have, hide those nifty modules that you would like to use now > and then. I also don't like to have simple modules part of a framework > because more often than not they become very dependent on the framework > architecture and since no one is going to refactor it, it's lost to the > framework. <snip> > I don't think that any other sorting than technological can work. In fact, > next time Ill write some kind of framework I'd see that I (seriously) write > the "technology" modules before I do any framework work.
This isn't in the same realm as the sorts of modules I would like to deploy. I have several CPAN modules to my name, all of which are technology-named. (e.g. Class::DBI::Cacheable, AxKit::XSP::BasicSession, etc). However, those modules - as well as the one you describe above - are intended to be used by developers, not end-users. For instance, I've been toying with the idea of doing an AxKit-based webmail solution. So, it would use tons of CPAN modules under the covers: AxKit, Mail::Internet, Mail::XML, Net::IMAP, Net::LDAP, etc. However, the real magic is in how these CPAN modules are tied in together to make an application. Those Perl modules that define the application logic, event frameworks and XML output methods for creating a functioning application should have a place on CPAN as well. But, where does one draw the line? Mail? WWW? AxKit? It crosses many different disciplines and doesn't fit well in any one namespace. A more complicated example is the Intranet application I'm developing at work. It's a customer management system for a cable ISP, which has been under development for 2 years and is being open sourced. It uses uses a plethora of Perl modules and has tons of functionality, which includes bandwidth management, email account creation, website creation, cable modem provisioning, etc. It prints out PDF reports, uses barcode scanners to assign modems, and talks via SNMP to access our cable modem management equipment. To sum up, it uses over 50 CPAN modules, yet doesn't fit well in any category. Since the whole framework is 100% Perl, I feel it would be worth it to publish it on CPAN, especially since the underlying Perl modules can be extended by other users. This is the kind of problem I'd like to solve with a new top level namespace. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc
