none of the things you're saying are wrong, but i (and i
suspect the group in general) have a different goal. see my
previous msgs to gunther :)
On Fri, 9 Nov 2001, Aaron Trevena wrote:
> On Thu, 8 Nov 2001, Perrin Harkins wrote:
>
> > > 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.
> >
> > Can't you just do something like a require() wrapped in an eval{}?
> >
> > I'm not against an XML config, although I've always been happy with perl
> > config files in the past. (I still want to see the layered config idea that
> > was discussed earlier.) It may be that a CGI implementation would need to
> > cache the data with Storable and stat the XML files to see if they've
> > changed.
>
> Having used config files written in perl, I can see there are benefits in
> them - speed primarily but also a great deal of flexibility at the same
> time. I'm sure that using perl for configuration is seen as a benefit of
> perl by many developers, perhaps even a part of the idiom.
>
> If you are checking whether or not the xml config file has been changed,
> you may as well create/generate/alter a perl config from that. This would
> mean that config can be written as XML but have the benefits of perl
> configs.
>
> Transforming XML into perl data structures isn't *that* hard and will be
> almost certainly be part of the config file processor anyway.. extending
> it to store or cache the perl config seems to offer a good return on
> relatively little investment...
>
> or I have I been inhaling from the perl crack pipe again?
>
> A.
>
>
