Hello Tim, and thanks for your reply. It was very helpful. (And also thanks for replying both to me and the module list, which in the past some people didn't do.)
On Fri, 30 May 2003, Tim Bunce wrote: > DOM shouldn't imply XML. But you could drop the D and expand the OM into > SQL::ObjectModel, or Class::SQLObjectModel, for example. Those are good suggestions, and look better than most of mine. > It's not trademarked. I'd say the benefits of including SQL in the > name outweigh any limitation it may imply. Nice to hear. > Frameworks can be intimidating to use. Requiring a significant 'buy in'. > I think you'd gain more users overall by breaking it up (all else being > equal). This sounds good and I'm inclined to agree. But its weighty enough that a third opinion *might* be helpful. So if anyone else can chime in and agree then I'm sold. (Then the next task will be figuring out what parts of my unified documentation to move over to the separate distro.) > Also I think you'll need to address Rosetta::Locale:: in a similar way. > Give it a new lease of life as an independantly useful set of modules. > (And you might be surprised to find that they become more widely used than > the other parts as it addresses a more common problem.) You're probably right. These modules would certainly be a lot *simpler* than the previously mentioned ones, which people seem to like. But the question remains whether this separate distro contains all the user strings (a pre-defined set of common database error messages) or simply contain the method to fetch and interpolate variables into Perl anonymous hash files. I suspect the former because the latter might be so simple there isn't worth being a module for it. > [EMAIL PROTECTED] is probably a better place to ask that. So maybe I'll try there soon. Just FYI: On a side note, I did send a different but related question to the [EMAIL PROTECTED] list, which I also subscribed to, since this seems to be made up mostly of database module developers. Thanks again. -- Darren Duncan
