Re: imap_idle
On Tuesday, 13 December 2005 at 17:04, Kyle Wheeler wrote:
> On Tuesday, December 13 at 01:50 PM, quoth Brendan Cully:
> >The poll call is actually a select call (and it works on my OS X.4.3
> >development system). I suppose it could fail depending on whether the
> >connection file descriptor is valid. This could be affected by the use
> >of $tunnel, SSL, SASL, or some mixture of those, and may also depend
> >on whether you're using gnutls or openssl. I've been using a raw
> >connection wrapped by SASL digest-md5.
>
> I don't use a tunnel either. I'm attaching the output of mutt -D. mutt
> -v says:
>
> -USE_POP +USE_IMAP +USE_SMTP -USE_GSS -USE_SSL +USE_GNUTLS +USE_SASL
>
> I'd like to be able to use the IDLE feature... what's the next step to
> figuring out what's going on?
are you connecting with SSL (which would use the gnutls code)? See if
things change if you connect without ssl. We can probably get poll to
work, but my current opinion is that IDLE won't work with binc until
binc fixes the bug described below.
> >But the failed poll should be fairly harmless - it should just disable
> >IDLE and go back to NOOP polls. It looks like binc is exhibiting the
> >same problem that dovecot does: it wants the DONE\r\n command and the
> >next IMAP command to be in two different TCP packets (it expects the
> >client to read the IDLE tagged response before continuing).
>
> I doubt it's being picky about which packets things are in -- bincimap
> runs via tcpserver (i.e. it doesn't have control over it's own
> connection).
to be more precise, I think it's reading all the available data after
+ idling... as the termination response, instead of just reading through
the new line. If the client waits until it's gotten the tagged
response before sending the next command, this works. But mutt is
pipelining them together. This is good for performance, so I'd rather
not give it up.
> >This shouldn't be required - the newline at the end of DONE should be
> >enough. Since the whole point of IDLE for me was to reduce round
> >trips, I don't want to add another one here. I guess you'll have to
> >disable imap_idle until binc gets fixed.
> >
> >I've never seen an untagged BAD response either. I don't think that's
> >in the RFC.
>
> I'll send this along to the binc devel team and see if they have any
> idea what's up.
Oh, ok. I was just about to write them a more politic version :)