I work for a development company and I've finally convinced the powers
that be
that releasing some of our in house developed modules might be a good
thing.  Nothing
really spectacular but, together our  modules facilitate rad cgi
development.

The problem is that some of the modules are interdependent, and some of
those
interdependancies are with modules that very nearly duplicate the
functionality,
(but differ interface wise) with some existing modules on CPAN.  These
modules
have been optimized for max speed as a suite, one complementing the
other.

As an example, we have a module that implements a Set class & another
that
implements graph manipulation, both of these are significantly less
functional
than their CPAN counterparts but are also significantly faster.

Another problem is that some of the modules don't seem to stand on their
own,
or at least are irrelevant or awkward without their sister modules.  As
an example
we have a template module that we use to describe our cgi output, and
one of its
routines imports and formats an array to hash ref.  We have another that
retrieves
just that format of data from a mysql database, and together those two
modules
enable a 5 line sql query -> html output.

Handy as  all heck, but the database module output is very awkward to
use  outside
the template module, too much typing!:
    eg. $data->[0]->{'huge_table_name.massive_field_name'}

What do you think we should do?  Should we contribute what modules we
have
that are easily categorized, eg. under the Text::   namespace?   Or
should we
group them together under some nested namespace?: like
CGI::SomethingDescriptive:: or is their another option?

Any advice you could give us would be much appreciated.  We've been
using
opensource software, perl and CPAN for some time now, and we feel it's
time we contributed something back, but where do we put it?



--
"Oh bother", said pooh, "Eeyore go get Ryan, every time I e-mail
tiggr it bounces".                            www.ryansfault.com
Because  even  a  poo bear  knows it's not his fault  its  Ryans



Reply via email to