On 2021-11-22 12:02:28, Oswald Buddenhagen wrote: > On Sun, Nov 21, 2021 at 12:59:28PM -0500, Antoine Beaupré wrote: >>https://anarc.at/blog/2021-11-21-mbsync-vs-offlineimap/ >> >>Let me know what you think. >> > well, apparently the manual page should mention the example file. ^^ > (i don't want the examples inline, as i loathe excessively long manual > pages.)
hehe. well, it's a matter of taste I guess. i also don't like excessively long manual pages either, but in this case this can fairly easily be solved by moving the configuration file documentation to a `mbsyncrc(5)` manpage. The examples could live there or in the main manpage. Or at least refer to the shipped examples file. > the question about the renaming can be implictly answered by mentioning > https://cr.yp.to/proto/maildir.html, but i guess i can plainly say > "strip the ,U=xxx" just as well. yeah, i expanded on that below. > progress logging under systemd wouldn't work very well - each update is > actually a line, only ended with \r instead of \n (which translates into > \r\n). this would utterly dwarf the output you're getting with -V, which > you already found too noisy. i guess the progress meter should be > rate-limited, but the real point is that progress reporting is kinda > anti-thetical to background operation. of course. i guess what i would like to see is a single summary line, at the end of the job. basically the last printf would be enough, i would guess. > the syntax of the config file is as tricky as any DSL, but it's actually > quite minimalistic. i could do away with the "weird" colons by moving > the box names into Patterns; this actually mirrors an item from the TODO > file. interesting! what i find really confusing about the config file syntax is that sections are really not obvious at first. it's really a trial-and-error process to generate a valid configuration file, and i think that could be improved. *not* using a DSL and instead a more "standard" format would help... >>I'm particularly curious to hear about >>performance on slow links, it seems like mbsync is significantly >>impacted compared to SMD. > > first make sure that the server uses compression, either via the > COMPRESS imap extension (you can watch the traffic with -Dn; use a cheap > action like -l) or via TLS (dunno how to test that - openssl s_client > might tell). i'm piping everything over `ssh -C`, so it should be using compression. i should really try reverting back to IMAP and see the difference... > the base imap protocol that mbsync uses isn't very efficient for > resyncs. a proper fix would require using the QRESYNC extension, but > that's a major project (also in the TODO). as a workaround, you can do > partial syncs, though it may be challenging to automate that > sufficiently to make it both reliable and convenient when working with > multiple clients. right. this is something interimap implements, fwiw: https://guilhem.org/man/interimap.1.html thanks for the feedback! a. -- Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts... - William Gibson _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
