I put it to harshly when I said starting from scratch. . In fact I am dabbling with linux networking stuff: ipvsadm, keepalived.and ip commands and some added configuration layers. Eventually I end up with the same data in different configuration files. keepalived polls services defined by ipvsadm so its configuration file repeats material needed for ipvsadm. Compatibility with installed stuff is a criteria as well.
So It is difficult to decide which configuration file is authoritative for what. Anyway I need to deal with inconsistencies between them. I intend to provide a Perl API to some C code extracted from these commands. But I am not sure I will be given the time to do it. What I want is to avoid to massage many configuration files but to have one that drives everything.
In other words, one should not always work by adding layers on top of layers in Perl (*) but must deal with C to reorganize and/or to provide an clean Perl API.
(*) later edition In Perl or any scripting language. My point was that because some managers know you can pee code in whatever language, they may prefer quick fixes over quick fixes and one ends up in a mess.
-- stefp
In reply to Re: Re: Downside of Perl (relative) popularity
by stefp
in thread Downside of Perl (relative) popularity
by stefp
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |