Proposal for removing some serialization limitations of define-configuration

Proposal for removing some serialization limitations of define-configuration

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 3426 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposal for removing some serialization limitations of define-configuration

[Felix Lechner via Development of GNU Guix and the GNU System distribution.]

Hi Tomas,

On Sun, Jun 23 2024, Tomas Volf wrote:

> 1. I need the serializer for `name' field to wrap the output of other
>    serializers.

Is it possible with nested configuration records (which I remember are
complicated to set up)?

> 2. I need to serialize key-file and key-type as one (since they belong on one
>    line).

Yeah, I've had that issue, too.  I am not sure the field-based
serializers are a general solution.

> I did not figure out how to achieve those except by a custom
> procedure: 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

I probably find the custom serializer, which is in one place, easier to
understand than passing the record around, but I'm ready to be convinced
otherwise.  In any event, I'm a newbie so please feel free to disregard.

Kind regards
Felix

Re: Proposal for removing some serialization limitations of define-configuration

[Attila Lendvai]

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


i have no time to verify this right now, but i think you should be able to write only the header and the wrapper in your custom serializer, and then iterate through the remaining fields of the config record, i.e. sans the `name` field.

you can inspect the current serializer for how to iterate through the fields, or better yet, how to call it recursively with the remaining fields.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Government does not grow by seizing our freedoms, but by assuming our responsibilities.”
	— Michael Cloud