gnu: home-services: mail: Improve serialization for Isync service. v1 APPLIED

Xinglu Chen: 1
 gnu: home-services: mail: Improve serialization for Isync service.

 1 files changed, 16 insertions(+), 1 deletions(-)

That’s what we have ‘boolean->true-or-false’ in (gnu
home-services-utils) for.  :)

Xinglu Chen <public@yoctocell.xyz> writes:

Andrew Tropin <andrew@trop.in> writes:

Xinglu Chen <public@yoctocell.xyz> writes:

Xinglu Chen <public@yoctocell.xyz> writes:

This is a current format.

Let's call this option 4.

Xinglu Chen <public@yoctocell.xyz> writes:

Xinglu Chen <public@yoctocell.xyz> writes:

[PATCH] gnu: home-services: mail: Improve serialization for Isync service. Export this patch

* mail.scm (%isync-all-caps-words): New variable.
(serialize-isync-config): Serialize symbols according to the Isync
naming conventions.  Serialize numbers.
---
The naming of symbols should be consistent across services, one
shouldn’t have to write 'symbol-name in one field and 'SymbolName in
another field.  Guix should take care of serializing 'symbol-name to
whatever format the program expects (camelCase, snake_case, etc.).

Andrew Tropin <andrew@trop.in>

3 years ago

From one point view it's cool, from another it will force us to cover
all corner cases like SSL, IMAP, etc, as you did below.  The problem is
that in some software, potentially, it can be much more difficult than
hardcoding 4 options.

Imagine such example with camel case:
(true-type-font? . true) will produce TrueTypeFont? = True, but it could

Xinglu Chen <public@yoctocell.xyz>

3 years ago

In this case it would make more sense to use (true-type-font? . #t),

Next

be that boolean value must be true in that config format.  We can
serialize cars and cdrs differently, but what if the grammar of the
target format is quite complex and we can't be sure if it's a value or
key?

Xinglu Chen <public@yoctocell.xyz>

3 years ago

If the grammar is very complex it just makes more sense to have an
“escape hatch” and let the user provide an opaque string or read from an
extenal file.

In this case, the format of the mbsync file looks pretty well-defined,
mbsync(1) lists all the available options.

Next

I'm not sure if we really want to play this game with converting cases.
Yes, it does give esthetic look, but for what price.

Xinglu Chen <public@yoctocell.xyz>

3 years ago

Most (if not all) of the services that provide Scheme bindings for a
configuration so far have an ‘uglify-field-name’ procedure, or some
equivalent thereof.  The same is true for Guix proper, I don’t see why
we should break this convention.

WDYT?

 gnu/home-services/mail.scm | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/gnu/home-services/mail.scm b/gnu/home-services/mail.scm
index bfb4284..f3a03c0 100644
--- a/gnu/home-services/mail.scm
+++ b/gnu/home-services/mail.scm
@@ -14,10 +14,25 @@
   #:export (home-isync-service-type
 	    home-isync-configuration))
 
+(define %isync-all-caps-words
+  '("ssl" "imap" "starttls" "imaps"))
+
 (define (serialize-isync-config field-name val)
+  ;; imap-store => IMAPStore
+  ;; user => User
+  (define (serialize-symbol symbol)
+    (let* ((str (symbol->string symbol)))
+      (string-join (map (lambda (word)
+                          (if (member word %isync-all-caps-words)
+                              (string-upcase word)
+                              (string-capitalize word)))
+                        (string-split str #\-))
+                   "")))
+
   (define (serialize-term term)
     (match term
-      ((? symbol? e) (symbol->string e))
+      ((? symbol? e) (serialize-symbol e))
+      ((? number? e) (format #f "~a" e))
       ((? string? e) (format #f "~s" e))
       (e e)))
   (define (serialize-item entry)

base-commit: 4317b9d171377b51547df3e2cc8dff80f65e47bb
-- 
2.32.0

Andrew Tropin <andrew@trop.in>

3 years ago

Xinglu Chen <public@yoctocell.xyz> writes: