Re: Perl

On Fri, Jul 21, 2006 at 01:20:48AM -0600, Tony Arkles wrote:
>
> On 20-Jul-06, at 3:52 PM, Greg Oster wrote:
>
> >"Steven Kurylo" writes:
> >>Here is the problem. I have a large hash which looks something
> >>like this:
> >>
> >>%networks = (
> >> 'name' => {
> >> filter => 'net 10.10.10.0/21',
> >> port => '234',
> >> },
> >>);
> >>
> >
> >Take a step back from things, and let the code be code, and the data
> >be data? (vs. doing the "data as code"?) (i.e. define a format for
> >a configuration file, and read+parse that file to build up %networks )
> >
> >Once you decide on a format for the config/data file, it'd be easy to
> >write a perl script to convert your existing "data as code" into just
> >the necessary data bits :)
>
> I don't want to come across as a big XML hater, but several of the
> other replies have reminded me of a quote: "Let's say you have a
> problem and you decide to solve it using XML. Now you have two
> problems."
>

I'll admit that I used to be an XML hater, back when it was the domain of
the marketeers that would sell it as a solution to all problems, before
there were really mature tools. Now that the marketeers have moved on to
selling J2EE or whatever the technology de jour is, the technical folks
have managed to do some good stuff with XML.

A couple of things XML can bring to the table:

- You get structure and labelling of data where it is obvious and useful to
  an interpereter (software or a person). The structure of the data is
  maintained - you define the structure of the date (object or relational/
  flat) is maintained in the data format and can be relatively clearly
  interpereted by people.

- There are XML editors available that can take an XSD (XML Schema) or DTD
  (Document Type Definition) and enforce the rules while editing. In this
  application, it can reduce errors in the config file.

- Unlike a line-per record delimited data formats, XML reduces much of the
  quoting and escaping necessary for not trivial field values.

- The tools to parse and access XML are mature and available in common
  software languages. In one or two lines of code the data is in a DOM
  tree and most of those will allow direct access via XPATH or searching/
  querying by element name.

- XSLT can translate the XML to something else ... different XML, HTML,
  CSV, ...

Flat files have their place, tinydns uses a : delimited file as an inter-
mediate format for DNS records. The format is quite unabiguous and machine
friendly however it's a little non-obvious to a human who is not working
with them all the time. Also, the fields are all alpha-numerics or .'s so
there is no need to worry about quoting anything.

Flat files are fine if they are read/written exclusively by one system. As
soon as the data is being exchanged between systems (different software apps,
platorms or even humans), XML starts looking like a better solution. XML is
an ideal data-interchange format. The trade-off is it consumes a lot of
space ... not a big deal now that discs and network bandwidth are both cheap.

Finally, not to sound like I'm completly shooting your idea down; you are
on the right track. I'd probably go once step further and go to CSV which
is easily opened. edited and manipulated in your spreadsheet program of
choice. There are perl libraries to parse CSV so you don't need to come up
with an ugly regex, just itterate through the data and create the perl hash.
As a free bonus, you can use a visual editor like a spreadsheet program.
Received on Fri Jul 21 02:04:45 2006