On Thu, Dec 10, 2015 at 9:27 AM, Oswald Buddenhagen <oswald.buddenha...@gmx.de> wrote:
[Re-CC'd the list. Since there was nothing private in your reply, assuming a mistake...] > On Wed, Dec 09, 2015 at 07:37:24PM +0100, Ęvar Arnfjörš Bjarmason wrote: >> On Wed, Dec 9, 2015 at 7:12 PM, Oswald Buddenhagen <o...@users.sf.net> wrote: >> > i didn't look much into the patch, but it seems excessive - git master >> > already has the DisableExtensions option, where you could just put >> > "COMPRESS" into. >> >> Yes I didn't notice that option. It's actually "DisableExtensions >> COMPRESS=DEFLATE" for me. >> > right > >> I've amended it to just change the manpage to show how to disable >> compression and discuss how you can use that in conjunction with >> stunnel & tcpflow to look at the raw IMAP traffic going over the wire: >> >> https://github.com/avar/isync/commit/1c6d37e4 >> >> That's in the avar/document-compression-disabling branch. >> >> Hopefully you can apply that patch. >> > i don't like making the man page "noisy" like that. examples should go > into mbsyncrc.sample (i'll grant that this file should be probably > mentioned somewhere in the man page, conventionally at the bottom under > FILES). It's your project, and I'm not going to try to shove a patch your way, but FWIW as a user of these types of tools I've never been disappointed with noisy manpages, but rather the opposite. It's easy to skim past examples. E.g. in this case I had an error indicating compression was involved, opened the manpage, looked for "compression", then after some Google searching found an old mailing list post noting how to manually hack the source to disable it. That was obviously out of date information since there's the "DisableExtension" option now, which illustrates the danger of relying on mailing list posts for documentation. Or do you just mean it's noisy in that it shouldn't be described inline when we're enumerating the options? I could re-send this by adding some EXAMPLES section at the end. Similar to the mplayer & GNU parallel manpages: http://linux.die.net/man/1/mplayer & https://www.gnu.org/software/parallel/man.html I also think that moving mbsyncrc.sample into the manpage would be more useful, I've been using this tool for a few weeks now (thanks for hacking on it b.t.w.!) and still hadn't discovered that sample file, whereas I've skimmed the manpage multiple times. > regarding the example itself, you're losing me on the way ... you > disable compression, but then it's about ssl? am i missing something? I wanted to be able to see the raw exchange between server & client, so even if it was some compression error the raw exchange would have been useless to me without disabling SSL. I.e. if the server really was sending an invalid zlib frame I'd need to be able to hexdump that. In the end the problem seemed to fix itself and I never figured out what was going on. > the idea of sniffing connections to ssl servers itself has merit, and > i've posted "howtos" to this list myself: > https://sourceforge.net/p/isync/mailman/message/34601461/ > your method of using a proper local socket and a network sniffer has > advantages over my suggestion to use strace on mbsync itself, so it's > probably a good idea to document both approaches. ------------------------------------------------------------------------------ _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
