On May 18, 2004 11:25 am, Chris Josephes wrote: > On Tue, 18 May 2004, Michael A Nachbaur wrote: > > 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. > > The provisioning application sounds pretty cool, and it would probably get > some feedback and use if it was published. > > Look over the custom modules you wrote and ask yourself the following > for each one. > > 1. Does it stand alone on its own merits and provide a public function, or > is it only really suitable when it's bundled with your application? > > 2. Will using an existing namespace in CPAN pollute that namespace with > modules that don't work well without the entire framework of your > application?
Where possible I have used existing CPAN modules, like DateTime, Class::DBI, and so forth. The Perl modules in this application implement the business logic that ties all those other CPAN modules together. For instance, I have classes that inherit from Class::DBI to represent my database, SAWA classes that implement the application's event handlers, and so forth. I have already broken off bits of the application into stand-alone CPAN modules where appropriate (see AxKit::XSP::BasicSession, Class::DBI::Cacheable, etc) and continue to do so as necessary. > Another thing to consider is does it need to be uploaded to CPAN in order > to be public? Why not SourceForge, which is geared towards programming > projects? Make one large tarball with the custom modules, include the > other modules if necessary, or consider building a Bundle::(AppName) module > to handle installing the rest. This one particular application is just one instance of a scenario where a Perl application can be distributed as 100% perl. CPAN is a wonderfully easy way to install modules, especially since dependancies can be automatically installed. Applications like AxKit or Apache::MP3 already reside on CPAN, but they have very specific functional areas they fit into. What I'm proposing is just continuing the same, except provide a dedicated namespace to applications themselves that can't fit reasonably anywhere else. -- Michael A. Nachbaur <[EMAIL PROTECTED]> http://nachbaur.com/pgpkey.asc
