I have a big collection of modules that are currently under the JCS:: namespace (my initials). Together, they are meant to form a sort of web application construction kit. They're still under development, but I intend to release them to CPAN eventually. I'm also considering releasing parts of the suit as they get closer to completion.
The modules are largely interdependent, although some subsets can exist in isolation. But all such subsets start from the lowest-level modules and go upwards in abstraction. Here are the major parts of the suite, roughly from the bottom up: * An object base class plus a simple method maker * A URI class * A set of DateTime utility functions * HTML objects (form objects) * A DBI wrapper * A library of SQL manipulation and generation functions * A db-backed object base class * A basic web application framework * An MVC-style web application base class First, a brief defense of a few of the things that seem like wheel reinvention: * A URI class - It actually uses the existing URI class, but stores the URI "in pieces" under the assumption that a URI will be manipulated many times, but serialized only once (or at least fewer times than it is manipulated). This usage pattern is true in my suite, thus the usefulness of the class. It also has some convenient URI manipulation methods that URI lacks. * A DBI wrapper / A db-backed object base class - Yes, there are already a bunch of these on CPAN...which means that, like me, each author wanted to do something, it not "better", then at least "differently" than any of his predecessors. TMTOWTDI! :) Moving on... Each component depends on some or all of the components above it in the list. So while some components (e.g., the HTML objects) would be useful in isolation, actually submitting them to CPAN outside of this "suite hierarchy" is a bit of a hassle (for the users and the developer) due to the dependencies. Let's look at two similar module suites already on CPAN: Mason and Maypole. Mason is actually HTML::Mason, of course, reflecting (I'd imagine) its creator's attempt to put it somewhere "logical" while not being too frivolous with the name: it assembles chunks of HTML like a mason building with bricks...or something. But not long after its introduction, it quickly became just "Mason" to developers. Furthermore, it also became clear that Mason is a lot more than just a way to assembles blocks of HTML. It is a more like a complete system for creating dynamic web sites and web applications. The HTML:: part of the class name, although well intentioned, is now just noise. Mason also includes things like its own method maker and various utility functions that could technically exist outside of Mason, but don't. Finally, there's the MasonX:: hierarchy which does away with the HTML:: baggage at last. Maypole is a more recent example. It's an MVC web application framework that avoids any pretense of being a "HTML builder" or any other sort of thing trying to find a home in an existing HTML::, Net::, Web::, HTTP::, or Apache:: namespace. It is essentially "branded." My suite is broader than either Mason or Maypole. In fact, it actually uses and depends on Mason (and possibly also Template Toolkit) as part of its web app framework. It's my intention to release the entire suite as a "branded" entity much like Mason, Maypole, or Bricolage, with a unique top-level namespace to be determined later. (Obviously JCS:: will not do.) I'm not sure if Maypole or Bricolage went through the module authors list, but perhaps Mason did, and ended up under HTML:: as some sort of appeasement to the class hierarchy Gods. If so, this was a mistake, and one I'd not like to repeat. I suspect the guardians of naming are already poo-pooing my intention to create a new top-level namespace for myself, but the sky did not fall when Maypole was introduced. Ditto for Alzabo, Rudesind, Bricolage, or even MasonX. Being nestled under Net:: or HTML:: or XML:: or whatever only makes sense for a certain class of modules. At some point, when the level of abstraction gets high enough, it's time to start assembling all of these reasonably nested, generic pieces into more complex "systems." Those systems will, by definition, not fit nicely into any part of the existing hierarchy. Trying to make them fit is disingenuous and leads to more confusion, not less. Someone looking for HTML manipulation modules will be quite surprised to run across a huge system like Mason sitting alongside things like HTML::Parser, for example. I think "branding" happens naturally for these suites simply because there are only so many generic names for "web application framework" or "templating system." I also think it's clear by now that branded names like AxKit, Mason, Maypole, or Bricolage are good fits for developer mindsets, even if they don't fit into the One True Taxonomy of CPAN (as if there is such a thing). As you can see, I'm pretty much sold on the "branded suite" idea. In addition to side-stepping naming issues entirely and, well, working as actual branding, it also avoids the dependency hell of distributing all of the major parts separately (possibly even in separate namespaces entirely) and then forcing the user to download everything "below" a given module anyway in an annoying cascade of prerequisites. Assuming I have made a convincing argument, only a few questions remain: * What should the branded name be? I already have a favorite picked, but I'm open to guidance (e.g. "no copyrighted names", although I know that one already :) * Is it okay, or advisable to release a "partial" suite and then fill in the rest of the components as they are completed? * Is it okay to release modules before the documentation has been completed? * These are all version "0.01" at this point. Is that sufficient to communicate the still-in-development nature of the suite, or should I simply not release anything unless it's completely documented, at the very least? I think the HTML objects module will be useful immediately, but it is still version 0.01, as are all the modules it depends on. All APIs are still subject to change, and likely will be so until 1.0. I'm assuming that's a well understood convention, and it will be in all the READMEs too. But the question remains: release partial or wait a while longer? Thanks for listening...I hope someone still reads this list, heh :) -John
