On Thu, Oct 23, 2014 at 03:02:08PM -0400, Wietse Venema wrote:
> > Postfix has a simple string interface for its key-value store. I
> > have an aversion against changing that into some binary protocol
> > with sub-record structure. Similar to my aversion against systemd
> > logging, among other things.
>
> JSON can be represented as printable ASCII, and circumvent some of
> my aversion against binary protocols. But wait, there is more.
Being somewhat old-fashioned, my initial mental model of multi-value
lists was TCL lists, somewhat simpler than JSON. But that's just
a user-interface question. Tcl lists are simpler when the elements
are just "words", but JSON has a lot more tooling and mind-share.
The question is then whether to optimize for ease of machine-parsing
or ease of human editing, and which is the better syntax for one
or the other.
Simple 3-element Tcl list:
abc def 123
Tcl list of two lists:
{abc def 123} {xyzzy elbereth}
> current:
> root: foo, bar
>
> becomes:
> "root" ["foo","bar"]
Tcl (key, value) list:
root {foo bar}
> To implement two-key lookup with Berkeley DB, we'd specify something
> like ["xxx","yyy"] as the real Berkeley DB database lookup key,
> where "xxx" is the first key and "yyy" the second one. In other
> words, it is faked with concatenation.
Tcl list with a two-element key and a three-element value:
{key1 key2} {val1 val2 val3}
> Now, suppose we have a single-key, multi-value access map entry
> in some PCRE table:
>
> /^(.+@example\.com)$/ ["warn redirecting $1", "redirect f...@example.net"]
>
> Here, the PCRE map would replace quotes and backslashes in the
> expansion of $number with JSON escape sequences, so that the expanded
> text cannot change the syntactical structure of the result.
Yes, the dictionary layer would have to honour the list structure.
This is big-time incompatible, since existing RHS values with
white-space would have to be enclosed in some sort of syntax to
indicate a single entity containing white-space.
--
Viktor.
