#18 JSON (or any other machine-readable format) config-file?

[Lockywolf]

mbsyncrc format is fairly simple, however, one willing to read that file in their program would have to either copy the parser from the isync source, or implement one ad-hoc.

Both seem to be error-prone. Perhaps, switch to json? In particular, now I am writing an IMAP IDLE monitor to trigger mail checking when a new message arrives, and I have to type the credentials three times (IDLE monitor, mbsync, smtp). I would rather try to just use the mbsyncrc file.

Could this be done?

[Oswald Buddenhagen]

well, no - the effort is not justified.

the usual way to centralize credentials is to use UserCmd/PassCmd in mbsyncrc.

note that there are already suitable monitors: http://mswatch.sourceforge.net/ and https://github.com/a-sk/node-imapnotify (and https://github.com/tim-smart/node-mbsync-watcher for the maildir side).

a properly integrated watcher inside mbsync is also under consideration; the list archive contains multiple related threads (keyword: IDLE). patches welcome!

[Lockywolf]

I do synchronize credentials with PassCnd. But I also want to synchronize accounts.

If I submit a patch for a json'ed .mbsyncrc, will it be accepted?

The node watcher is abandoned, and mswatch probably does the "same" thing, but I've been using my own python I've for quite a lot, and I'm quite happy with it.
But now it has its own config file, and I want do remove the duplication.

I actually have already written the parser, but it's not robust. I would, obviously, prefer to have a unified one.

[Oswald Buddenhagen]

i suggest you auto-generate the mbsyncrc from whatever format you prefer. [#17 ] is kinda complementary to this and contains relevant proposals.

If I submit a patch for a json'ed .mbsyncrc, will it be accepted?

no, because it would be bloat, and i would still have the review and maintenance effort - for a feature i don't find compelling.

you're basically making the argument for "linux registry" - which failed and resulted in "elektra", which is also barely relevant.