* gnu/services/telephony.scm (string-or-computed-file?)
(string-list?, account-fingerprint-list?): New procedures.
(maybe-string-list, maybe-account-fingerprint-list)
(maybe-boolean, maybe-string, jami-account-list): New configuration field
types.
(serialize-string-list, serialize-boolean, serialize-string)
(jami-account, jami-account->alist, jami-configuration)
(jami-account-list?, jami-account-list-maybe): New procedures.
(%jami-accounts): New variable.
(jami-configuration->command-line-arguments): New procedure.
(jami-dbus-session-activation, jami-shepherd-services): New procedures.
(jami-service-type): New variable.
* gnu/build/jami-service.scm: New file.
* gnu/tests/data/jami-dummy-account.dat: Likewise.
* gnu/tests/telephony.scm: Likewise.
* gnu/local.mk (GNU_SYSTEM_MODULES): Register them.
* Makefile.am (SCM_TESTS): Register the test file.
(dist_patch_DATA): Register the new data file.
* doc/guix.texi (Telephony Services): Document it.
Sometimes two configurations might have the same types for their field values,
but the values might be serialized in two completely different
ways (e.g. because the two programs have different configuration languages).
An example of this would be the ‘serialize-boolean’ procedure in (gnu services
mail) and (gnu services getmail). They both serialize a boolean value, but
because the Dovecot’s configuration language has a different syntax to the
configuration language for Getmail, two different procedures have to be
defined.
One way to workaround this would be to specify custom serializers for many
fields in order to separate the serialization of the values that have the same
type but serialize in different ways. This could get very tedious, especially
if there are many configurations in the same module.
Another way would be to move one of the configurations to its own module, like
what was done with (gnu services getmail). However, this would mean that
there would be multiple modules containing configurations for related
programs, e.g. we have (gnu services mail) and (gnu services getmail), it
doesn’t make much sense to keep the Getmail configuration in its own module.
This patch will allow one to write something like this:
(define-configuration foo-configuration
(bar
(string "bob")
"Option bar.")
(prefix bar-))
and the value of the ‘bar’ field would be serialized using a procedure named
‘bar-serialize-string’ instead of just ‘serialize-string’.
* gnu/services/configuration.scm (define-maybe-helper): Accept ‘prefix’
argument for using serializer with custom prefix.
(define-maybe): Pattern match on ‘prefix’ literal.
(define-configuration-helper): Accept ‘prefix’ argument for using serializer
with custom prefix.
(define-configuration): Pattern match on ‘prefix’ literal.
* tests/services/configuration.scm ("serialize-configuration with prefix"):
New test.
Signed-off-by: Ludovic Courtès <ludo@gnu.org>
Before this change, using define-maybe along define-configuration with the
no-serialization syntactic keyword would result in the following warning:
warning: possibly unbound variable `VARIABLE-NAME'
This change introduces the define-maybe/no-serialization variant that does
away with defining a serialization helper procedure, which makes it possible
to avoid the above warning.
* gnu/services/configuration.scm (define-maybe/no-serialization): New syntax.
(define-maybe-helper): New procedure.
(define-maybe): Define syntax using the above procedure.
* tests/services/configuration.scm (tests): Fix module name.
(custom-number-serializer): Do not print to standard output.
(maybe-number?, serialize-maybe-number): New procedures defined via the
define-maybe macro.
(config-with-maybe-number): New configuration.
(serialize-number): New procedure.
("maybe value serialization"): New test.
(maybe-string?): New procedure defined via the define-maybe/no-serialization
macro.
(config-with-maybe-string/no-serialization): New configuration.
("maybe value without serialization no procedure bound"): New test.
* gnu/services/linux.scm (<zram-device-configuration>): New record.
(zram-device-service-type): New variable.
* doc/guix.texi (Linux Services): Document it.
* tests/services/linux.scm (zram-swap-device-test): New tests.
* gnu/services/linux.scm: New file.
* tests/services/linux.scm: Add test.
* Makefile.am (SCM_TESTS): Register test.
* doc/guix.texi (Linux Services): Add a new section and document the new
service and its configuration.
