Re: mbsync vs offlineimap comparison
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
Re: mbsync vs offlineimap comparison
On 2021-11-22 16:29:35, Oswald Buddenhagen wrote: > On Mon, Nov 22, 2021 at 09:29:13AM -0500, Antoine Beaupré wrote: >>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. > > most of the manual is about the config file, so that wouldn't *really* > solve the problem (having the example in the main page would be kinda > backwards). but i like the idea of referring to the example file (i've > seen precedents for that on my debian system), so that's a settled > matter anyway. ^^ i still think the config file docs should be split out, TBH. the example could live there too. but it's your call. :) >>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. > > that's a good idea. i'll even make it a bit more human-readable. that's amazing, and unexpected, thanks! :) >>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. > > the manual explains it thoroughly and the example file kinda hints at it > (though i could make it more explicit), so someone approaching the whole > thing more systematically shouldn't have a problem. :P yeah, i guess that's my point. when I was 20 years younger, I had a lot more time on my hands and didn't mind things like that. i would learn everything about everything, and that worked. now, i'm much less patient and expect things to just work out of the box without me having to figure out what a "channel" is. :) >>*not* using a DSL and instead a more "standard" format would help... >> > well, that ship has kinda sailed even before i took over the project. > and i don't see this as a big enough pain point to warrant a format > change. sure, that's not something I think you can fix easily, and probably does not warrant a major change, unless it would also fix other limitations. it's just one of those little quirks every project has, basically... a. -- We will create a civilization of the Mind in Cyberspace. May it be more humane and fair than the world your governments have made before. - John Perry Barlow, 1996 A Declaration of Independence of Cyberspace ___ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
Re: mbsync vs offlineimap comparison
On Mon, Nov 22, 2021 at 09:29:13AM -0500, Antoine Beaupré wrote: 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. most of the manual is about the config file, so that wouldn't *really* solve the problem (having the example in the main page would be kinda backwards). but i like the idea of referring to the example file (i've seen precedents for that on my debian system), so that's a settled matter anyway. ^^ 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. that's a good idea. i'll even make it a bit more human-readable. 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. the manual explains it thoroughly and the example file kinda hints at it (though i could make it more explicit), so someone approaching the whole thing more systematically shouldn't have a problem. :P *not* using a DSL and instead a more "standard" format would help... well, that ship has kinda sailed even before i took over the project. and i don't see this as a big enough pain point to warrant a format change. ___ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
Re: mbsync vs offlineimap comparison
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.) 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. 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. 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. 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). 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. ___ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
