Proposal for removing some serialization limitations of define-configuration

[Tomas Volf]

Hello,

I am trying to define configuration for my port of OpenBSD's acme-client, and
got bit stuck with limitations of the define-configuration's serialization.

First let me describe my problem (maybe there is a solution already).  I want to
generate this piece of configuration:

    authority letsencrypt {
        api url "https://acme-v02.api.letsencrypt.org/directory";
        account key "/some/path.pem" rsa
        contact "mailto:who@knows";
    }

I have put together this configuration for it (for now let us ignore that it
will not know how to serialize the values, it does not matter):

    (define-configuration acme-client-authority
      (name
       symbol
       "The name by which this authority can be referenced.")
      (key-file
       string
       "Specify a file used to identify the user of this certificate 
authority.")
      (key-type
       (symbol 'ecdsa)
       "Key type to use as a symbol.  Supported types are @samp{rsa} and
    @samp{ecdsa}.")
      (api-url
       string
       "Specify the url under which the ACME API is reachable.")
      (contact
       (maybe-string %unset-value)
       "Contact URL that the authority can use to contact the client for issues
    related to this account.  Optional."))

I realized I have two problems I do not know how to solve:

1. I need the serializer for `name' field to wrap the output of other
   serializers.
2. I need to serialize key-file and key-type as one (since they belong on one
   line).

Now, are those possible?  If yes, please tell me and feel free to ignore rest of
this email.



I did not figure out how to achieve those except by a custom procedure:

    (define (serialize-acme-client-authority authority)
      (match-record authority <acme-client-authority>
                    (name key-file key-type api-url contact)
        #~(simple-format #f "\
    authority ~A {
        account key \"~A\" ~A
        api url \"~A\"
        ~A
    }
    "
                         #$(symbol->string name)
                         #$key-file
                         #$(symbol->string key-type)
                         #$api-url
                         #$(if (maybe-value contact)
                               (simple-format #f "contact \"~A\"" contact)
                               "# contact not set"))))

This has the obvious maintenance issues though, so I think it would be nice to
be able to utilize the existing serializer infrastructure for this, therefore I
would like to propose two changes:

1. Add OPTION* `(wrapper BEGIN END)', where `BEGIN' and `END' would be
   procedures with arity of 3 taking `field-name', `value', `record' arguments
   to be called before/after all other fields are serialized.

   If multiple fields are marked like this, the order is unspecified.

2. Allow serializers to optionally take 3rd argument `record', passing the
   record currently being serialized.

The 1. will allow to produce `authority NAME {' in BEGIN and `}' in END.  The
2. will allow me to set `empty-serializer' on `key-type' and retrieve its value
using `acme-client-authority-key-type' while serializing the `key-file' field
via the (new) `record' argument.  And it is fully backwards compatible.

What do you think?  Would these extensions make sense?

Thanks for reading and commenting and have a nice day,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

signature.asc
Description: PGP signature