[augeas-devel] [PATCH] Lens and transform for xinetd.conf

[David Lutterkort]

On Mon, 2008-05-05 at 18:13 -0700, David Lutterkort wrote:
> Lens and transform for xinetd.conf

A few comments are probably in order to explain better what is going on
with xinetd.aug and why:

      * I wanted to use xinetd to write a lens that follows the "native"
        parser as closely as possible; for example, I went to the
        trouble of listing all possible attributes for a service and for
        the defaults entry.
      * For an attribute 'attr' whose value is a list, the list is split
        and stored in a tree of the form 'attr/value[n]'
      * If an attribute's value is a list and can have values added to
        the list resp. removed from the list ('attr += val' and 'attr -=
        val' in the config file) the first node under attr will be 'add'
        resp. 'del'

The list representation is a little clunky:
        { "attr"                               (* Schema 1 *)
            { "value" = "v1" }
            { "value" = "v2" } }
I would have liked to avoid the extra "value" nodes and build something
like
        { "attr" = "v1" }                      (* Schema 2 *)
        { "attr" = "v2" }

But the typechecker won't let me. It's actually an interesting interplay
between the typechecker and a limitation of the language: the lens to
parse the "body" (everything between the "{" and "}") of a service looks
something like

        let service = Util.del_str "\n{\n" . (comment|attr1|...|attrN)* . Util.del_str "\n}\n"

where "attr1" through "attrN" are lenses to match different attributes
like "log_on_failure" and "port" (it's not really how this is written in
xinetd.aug, but the difference is immaterial)

Trouble strikes when trying to produce a tree according to Schema 2 when
the tree gets transformed back into a string: Augeas doesn't know
whether to produce
        attr = v1 v2                            (* Output 1 *)
or
        attr = v1                               (* Output 2 *)
        attr = v2
because of the * iteration in service. Disambiguating that is really the
reason to use Schema 1, as xinetd.aug does now.

The use of the * iteration in the service lens is actually not even the
right thing: each attribute can only be used once in an xinetd file, so
Output 2 is not even legal for xinetd; xinetd really only accepts
permutations of the legal attributes, not full * iteration of them. But
writing that as a lens is a nightmare, both because there's no notation
in the language, and more importantly because the resulting regular
expressions would become intractably large; the service lens would need
to be rewritten as
        
        let service = Util.del_str "\n{\n"
                    . permute comment* attr1? attr2? ... attrN?
                    . Util.del_str "\n}\n"
        
for some fictional 'permute' combinator; in the case of xinetd there are
around 50 legal attributes, resulting in a union of 50! ~ 10^64
concatenations of the form attr_i1 . attr_i2 . ... . attr_iN. Not
tractable.

David