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.
--
<A HREF = "http://termisoc.org/~betty";> Betty @ termisoc.org </A>
"As a youngster Fred fought sea battles on the village pond using a
complex system of signals he devised that was later adopted by the Royal
Navy. " (this email has nothing to do with any organisation except me)
