On Thu, 8 Nov 2001, Gunther Birznieks wrote: > web.xml should not exist as it does in java servlet API. > It should be an optional confile file written in Perl as > Perl data structures (hashes of hashes). This is much > more efficient and thin and will make porting servlet > API to be reasonably fast for CGI users much easier. SO > more like web.pl with web.xml being optional if XML is > really the preferred choice.
i tend to disagree. my only concrete reason for preferring xml, other than that it "feels" right ;), is that you get much better error handling right out of the box, especially when you turn on validation. that's something that would have to be implemented as part of a perl-based config file processor. something just makes my stomach turn, tho, wrt using code-based config files. they are higher-level artifacts than code and should be expressed in a higher level language. it's my belief that this makes it easier for non- or little-coding admins to configure and integrate. but of course i can't prove this. and maybe it's the group's concensus that this type of user is not our target. > We also do the same thing in our Java Toolkit anyway. > web.xml hardly contains anyhint other than a pointer to > our REAL config XML file for our java servlets where we > have a much much richer config API than Servlet's allow can you point us at an example of this config api? > This is exactly the right way to do it. I've been > posting off and on for over a year on the Mod_perl list > (usually now to encourage people to start naming things > right) that making something into an Apache::* module > really sucks unless that's what it really is because it > confuses people into thinking the module is apache only > when it might not be (eg Apache::Session or Apache::DBI > naming really annoys me)... i wonder if we can't elect a committee to review the namespace and recommend name changes, deprecations of redundant modules, refactoring, etc. hm. better suited to the modperl list i guess. > I like the idea of using the servlet API. But I think it > requires warping into being efficient for Perlisms. > Otherwise it is really just following the crowd. i'd like to hear your other thoughts on the subject. hopefully you get time to write them sometime soon! thanks.
