On Fri, 9 Nov 2001, Gunther Birznieks wrote: > I don't really believe that common problems are easier > to find with XML than with Perl constructs.
heh. > Perl is a scripting language and is perfect for > representing scriptable configs instead of static XML > documents. It's way more flexible. i'm talking about web.xml here man. there is no scripting. > Well, servlets allow you to set up params in web.xml but > they are very flat. > > What we do is instead have a single param called > ConfigFile which points to a location of a configuration > file. com.eXtropia.servlet then will take the value of > ConfigFile and pass it to com.eXtropia.config and create > a config object. see, that's really cool. but you've already got it set up exactly the way you should. web.xml is not for configuring arbitrary application-specific objects. it's for configuring those objects provided by the servlet container that are mandated to exist by the servlet spec and as such all web applications can expect to be configured and to operate in exactly the same way in any container. the parameters configured in web.xml are static in nature. when you want to configure things specific to your application, the technique of specifying a config file as a context init parameter is widely used, and i think a good model for us. this config file can be xml, properties, perl code, ini, whatever you prefer. what do you think? > Anyway, I think it is reasonable to support XML for > orthogonality with Java Servlet, but I think it is a > shame to move away from Perlisms because I just feel > like Perl supports so much more than Java that it can > make use of this stuff. and the flip side is, we shouldn't try to make perl do everything for us just because it can. obviously it's extremely powerful, that's why we like it so much. but i'm thinking in terms of administrative ease-of-use for non perl coders and in terms of possible tool support. in those terms, xml seems the better choice. still, this does seem to be a hotly debated topic, so whenever we have a voting structure in place, i will put this up for a vote. > Well, I think there is also a thought that all the > Apche::* modules basically makes mod_perl seem very > rich. So it makes mod_perl look quite good. So oh no! if we need to have a bunch of redundant and/or crap modules on cpan in order to look good outside our own community, we have a really big problem. > marketing-wise I think it's better for mod_perl, but > worse for Perl as a whole. Plus it's extra work. I am > not sure what would happen if people started refactoring > CPAN. I think it would be quite interesting, but I am > not sure it would work. i'm just suggesting that recommendations be made. > Consider what would happen if it took 4 weeks to > refactor something, so the owner spends 2 weeks doing it > and announcing a beta but then all of a sudden has other > work to do, so the module becomes in Limbo with people > still using the old version but anticipating the new one > and being annoyed that they have to wait longer for the > revised API. well that's always the case, isn't it? we just have to work within the normal open source development life cycle, whatever the project.
