Menu
▾
▴
imaplib2-devel — imaplib2 development list
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
(38) |
Jul
(8) |
Aug
(9) |
Sep
(5) |
Oct
(8) |
Nov
|
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(8) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(4) |
Oct
(4) |
Nov
|
Dec
(3) |
| 2016 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Piers L. <pi...@ja...> - 2012-11-14 01:30:45
|
On Tue, 13 Nov 2012 15:06:18 -0500, Dave Abrahams wrote:
>
>
> Check it out. The first run is with imaplib2, the second with imaplib.
>
> --8<---------------cut here---------------start------------->8---
> pluto:~ dave% time python -c 'from imaplib2 import *; s = IMAP4_stream("/opt/local/libexec/dovecot/imap"); s.open(); s.select("INBOX")'
> imap(dave): Info: Connection closed in=20 out=721
> imap(dave): Info: Connection closed in=18 out=694
> python -c 0.04s user 0.02s system 0% cpu 30.159 total
> pluto:~ dave% time python -c 'from imaplib import *; s = IMAP4_stream("/opt/local/libexec/dovecot/imap"); s.open(); s.select("INBOX")'
> imap(dave): Info: Connection closed in=20 out=721
> imap(dave): Info: Connection closed in=18 out=694
> python -c 0.04s user 0.02s system 64% cpu 0.086 total
> --8<---------------cut here---------------end--------------->8---
>
> If I don't try to open(), it goes fast:
>
> --8<---------------cut here---------------start------------->8---
> pluto:~ dave% time python -c 'from imaplib2 import *; print IMAP4_stream("/opt/local/libexec/dovecot/imap").select("INBOX")'
> ('OK', ['44'])
> imap(dave): Info: Connection closed in=38 out=1070
> python -c 0.04s user 0.02s system 34% cpu 0.161 total
> --8<---------------cut here---------------end--------------->8---
Hi Dave,
Actually, I'm surprised it finishes at all. Calling "open" is redundant
immediately after instantiation, as open is already called in __init__.
So you are opening two simultaneous streams here. The differences between imaplib and imaplib2 under these circumstances are probably due to the
use of threading in the second, but I'm only guessing.
So your second run above is the correct usage.
Hope that helps.
Piers Lauder
|
|
From: Dave A. <da...@bo...> - 2012-11-14 01:24:22
|
on Tue Nov 13 2012, Piers Lauder <piers-AT-janeelix.com> wrote: > Hi Dave, > > Actually, I'm surprised it finishes at all. Calling "open" is redundant > immediately after instantiation, as open is already called in __init__. > So you are opening two simultaneous streams here. The differences > between imaplib and imaplib2 under these circumstances are probably > due to the > use of threading in the second, but I'm only guessing. > > So your second run above is the correct usage. > > Hope that helps. It does; thank you very much! -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost |
|
From: Dave A. <da...@bo...> - 2012-11-13 20:06:34
|
Check it out. The first run is with imaplib2, the second with imaplib.
--8<---------------cut here---------------start------------->8---
pluto:~ dave% time python -c 'from imaplib2 import *; s = IMAP4_stream("/opt/local/libexec/dovecot/imap"); s.open(); s.select("INBOX")'
imap(dave): Info: Connection closed in=20 out=721
imap(dave): Info: Connection closed in=18 out=694
python -c 0.04s user 0.02s system 0% cpu 30.159 total
pluto:~ dave% time python -c 'from imaplib import *; s = IMAP4_stream("/opt/local/libexec/dovecot/imap"); s.open(); s.select("INBOX")'
imap(dave): Info: Connection closed in=20 out=721
imap(dave): Info: Connection closed in=18 out=694
python -c 0.04s user 0.02s system 64% cpu 0.086 total
--8<---------------cut here---------------end--------------->8---
If I don't try to open(), it goes fast:
--8<---------------cut here---------------start------------->8---
pluto:~ dave% time python -c 'from imaplib2 import *; print IMAP4_stream("/opt/local/libexec/dovecot/imap").select("INBOX")'
('OK', ['44'])
imap(dave): Info: Connection closed in=38 out=1070
python -c 0.04s user 0.02s system 34% cpu 0.161 total
--8<---------------cut here---------------end--------------->8---
--
Dave Abrahams
BoostPro Computing Software Development Training
http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
|
|
From: Damien C. <dam...@gm...> - 2012-06-15 12:16:42
|
Hi, I would like to use offlineimap to download my emails from gmail. Unfortunately, offlineimap is always stuck at message 102. I'm available on IRC freenode under name DamienCassou if you need me. More information at http://comments.gmane.org/gmane.mail.imap.offlineimap.general/5564 Best, -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
|
From: Piers L. <pi...@ja...> - 2012-04-22 11:28:31
|
On Tue, 3 Apr 2012 07:49:17 +0400, Eygene Ryabinkin wrote: > ... > > > > The second one works around the old bug in Python that was fixed > > > in the early versions of 2.6, but since OfflineIMAP documentation > > > says that 2.6 is supported, it will be good to have it really fully > > > supported, > > http://codelabs.ru/patches/offlineimap/6.5.2.1-imaplib2-bug-3473-workaround.diff > > for this one, I would suggest that you send it directly to the imaplib2 > > list, because I would prefer to bundle an unmodified upstream version if > > possible at all. I'm copying in the imaplib2 list in this reply, so > > let's see if the imaplib2 maintainer takes it. > > OK, that's fine. Gentlemen from the imaplib team, is the patch OK > or it should be reworked? This patch is redundant - it was fixed some time back. |
|
From: Eygene R. <re...@fr...> - 2012-04-20 05:24:38
|
Thu, Apr 19, 2012 at 05:54:37PM +0200, Sebastian Spaeth wrote: > Eygene Ryabinkin <re...@fr...> writes: > > Sebastian, may be it is the time to put the new imaplib2 to the master > > branch and test it for a while? > > Eygene, I just bumped the upstream imaplib2 in the 'next' branch to the > latest version. We were indeed 4 releases behind or so. Thus, improved > imaplib2 will be in the next OLI release. Thanks a lot! -- Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] |
|
From: Sebastian S. <Seb...@SS...> - 2012-04-19 15:54:57
|
Eygene Ryabinkin <re...@fr...> writes: > Sebastian, may be it is the time to put the new imaplib2 to the master > branch and test it for a while? Eygene, I just bumped the upstream imaplib2 in the 'next' branch to the latest version. We were indeed 4 releases behind or so. Thus, improved imaplib2 will be in the next OLI release. Thanks for the heads up. Sebastian |
|
From: Sebastian S. <seb...@ss...> - 2012-04-08 22:30:29
|
Eygene Ryabinkin <re...@fr...> wrote: >> As far as I'm aware, this has been fixed for some time in imaplib2. >> >> The fix was to put the keyword arguments before the *args. Please let >> me know if it doesn't, in fact, work. > >Yep, it works in my simple tests and works with OfflineIMAP where I had >patched the relevant lines in the _simple_command(). > >Sebastian, may be it is the time to put the new imaplib2 to the master >branch and test it for a while? Uhh, I usually try to bundle the latest imaplib2. I'll see if I missed an update next Tuesday. Sebastian -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
|
From: Eygene R. <re...@fr...> - 2012-04-03 04:11:20
|
Piers, good day. Tue, Apr 03, 2012 at 01:19:33PM +1000, Piers Lauder wrote: > On Mon, 02 Apr 2012 23:53:02 +0200, Sebastian Spaeth wrote: > > http://codelabs.ru/patches/offlineimap/6.5.2.1-imaplib2-bug-3473-workaround.diff > > for this one, I would suggest that you send it directly to the imaplib2 > > list, because I would prefer to bundle an unmodified upstream version if > > possible at all. I'm copying in the imaplib2 list in this reply, so > > let's see if the imaplib2 maintainer takes it. > > As far as I'm aware, this has been fixed for some time in imaplib2. > > The fix was to put the keyword arguments before the *args. Please let > me know if it doesn't, in fact, work. Yep, it works in my simple tests and works with OfflineIMAP where I had patched the relevant lines in the _simple_command(). Sebastian, may be it is the time to put the new imaplib2 to the master branch and test it for a while? Thanks! -- Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] |
|
From: Eygene R. <re...@fr...> - 2012-04-03 04:05:16
|
Sebastian, good day. Mon, Apr 02, 2012 at 11:53:02PM +0200, Sebastian Spaeth wrote: > Eygene Ryabinkin <re...@fr...> writes: > > I have two patches that will improve the compatibility of OfflineIMAP > > with Python 2.6. The first one cures Curses.py, > > http://codelabs.ru/patches/offlineimap/6.5.2.1-fix-super-usage.diff > > thanks for the patches and very sorry for my non-response time. I kind > of suffered an email breakdown for a few weeks, but I should be back > now and am in the process of catching up. > > I have applied the first patch. Thanks. Thanks a lot! > > The second one works around the old bug in Python that was fixed > > in the early versions of 2.6, but since OfflineIMAP documentation > > says that 2.6 is supported, it will be good to have it really fully > > supported, > http://codelabs.ru/patches/offlineimap/6.5.2.1-imaplib2-bug-3473-workaround.diff > for this one, I would suggest that you send it directly to the imaplib2 > list, because I would prefer to bundle an unmodified upstream version if > possible at all. I'm copying in the imaplib2 list in this reply, so > let's see if the imaplib2 maintainer takes it. OK, that's fine. Gentlemen from the imaplib team, is the patch OK or it should be reworked? -- Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] |
|
From: Piers L. <pi...@ja...> - 2012-04-03 03:51:42
|
On Mon, 02 Apr 2012 23:53:02 +0200, Sebastian Spaeth wrote: > > > Good day. > > > > I have two patches that will improve the compatibility of OfflineIMAP > > with Python 2.6. The first one cures Curses.py, > > http://codelabs.ru/patches/offlineimap/6.5.2.1-fix-super-usage.diff > > Hi Eygene, > > thanks for the patches and very sorry for my non-response time. I kind > of suffered an email breakdown for a few weeks, but I should be back > now and am in the process of catching up. > > I have applied the first patch. Thanks. > > > The second one works around the old bug in Python that was fixed > > in the early versions of 2.6, but since OfflineIMAP documentation > > says that 2.6 is supported, it will be good to have it really fully > > supported, > http://codelabs.ru/patches/offlineimap/6.5.2.1-imaplib2-bug-3473-workaround.diff > for this one, I would suggest that you send it directly to the imaplib2 > list, because I would prefer to bundle an unmodified upstream version if > possible at all. I'm copying in the imaplib2 list in this reply, so > let's see if the imaplib2 maintainer takes it. As far as I'm aware, this has been fixed for some time in imaplib2. The fix was to put the keyword arguments before the *args. Please let me know if it doesn't, in fact, work. (In imaplib2 version 2.33, those lines are:- if 'callback' in kw: # Note: old calling sequence for back-compat with python <2.6 self._command(name, callback=self._command_completer, cb_arg=kw, cb_self=True, *args) return (None, None) ) Piers Lauder. |
|
From: Sebastian S. <Seb...@SS...> - 2012-04-02 22:50:55
|
Eygene Ryabinkin <re...@fr...> writes: > Good day. > > I have two patches that will improve the compatibility of OfflineIMAP > with Python 2.6. The first one cures Curses.py, > http://codelabs.ru/patches/offlineimap/6.5.2.1-fix-super-usage.diff Hi Eygene, thanks for the patches and very sorry for my non-response time. I kind of suffered an email breakdown for a few weeks, but I should be back now and am in the process of catching up. I have applied the first patch. Thanks. > The second one works around the old bug in Python that was fixed > in the early versions of 2.6, but since OfflineIMAP documentation > says that 2.6 is supported, it will be good to have it really fully > supported, http://codelabs.ru/patches/offlineimap/6.5.2.1-imaplib2-bug-3473-workaround.diff for this one, I would suggest that you send it directly to the imaplib2 list, because I would prefer to bundle an unmodified upstream version if possible at all. I'm copying in the imaplib2 list in this reply, so let's see if the imaplib2 maintainer takes it. Sebastian |
|
From: Nicolas S. <nic...@la...> - 2012-02-22 16:30:28
|
Looks like a imaplib issue; cc'ing imaplib2 mailing list.
On Mon, Feb 20, 2012 at 05:28:47PM +0530, Sriram ET. wrote:
> I have just installed v6.5.2.1 on MacOS X Lion using Homebrew. I have
> customized the simple configuration for a single imap account on my
> company's Lotus Notes based server. When I attempt to start the first
> sync, I first get queries for my password and then I get the following
> error. I could not find any answers quickly using Google. Can anyone throw
> some light on this issue? Am I doing something stupid?
> �*** Finished account 'Cleartrip' in 0:04
> [thread]: Unregister thread 'Account sync Cleartrip'
> ERROR: Exceptions occurred during the run!
> ERROR: While attempting to sync account 'Cleartrip'
> � 'NoneType' object has no attribute 'group'
> Traceback:
> � File
> "/usr/local/Cellar/offline-imap/[1]6.5.2.1/libexec/offlineimap/accounts.py",
> line 231, in syncrunner
> � � self.sync()
> � File
> "/usr/local/Cellar/offline-imap/[2]6.5.2.1/libexec/offlineimap/accounts.py",
> line 287, in sync
> � � remoterepos.getfolders()
> � File
> "/usr/local/Cellar/offline-imap/[3]6.5.2.1/libexec/offlineimap/repository/IMAP.py",
> line 266, in getfolders
> � � imapobj = self.imapserver.acquireconnection()
> � File
> "/usr/local/Cellar/offline-imap/[4]6.5.2.1/libexec/offlineimap/imapserver.py",
> line 298, in acquireconnection
> � � imaputil.imapsplit(listres[0])[1:]
> � File
> "/usr/local/Cellar/offline-imap/[5]6.5.2.1/libexec/offlineimap/imaputil.py",
> line 152, in imapsplit
> � � retval.append(m.group('quote'))
>
> References
>
> Visible links
> 1. http://6.5.2.1/libexec/offlineimap/accounts.py
> 2. http://6.5.2.1/libexec/offlineimap/accounts.py
> 3. http://6.5.2.1/libexec/offlineimap/repository/IMAP.py
> 4. http://6.5.2.1/libexec/offlineimap/imapserver.py
> 5. http://6.5.2.1/libexec/offlineimap/imaputil.py
--
Nicolas Sebrecht
|
|
From: Sebastian S. <Seb...@SS...> - 2012-02-18 08:38:37
|
SOmehow the patches sent with git sent-email did not come through to the list it seems. Please find the 4 patches attached to this mail. It does not make imaplib2 python3-compatible but it brings us a step further without losing python2 compatability. Thanks for considering these. Sebastian |
|
From: Sebastian S. <seb...@ss...> - 2012-02-17 19:57:59
|
On Fri, 17 Feb 2012 12:55:37 +1100, Piers Lauder <pi...@ja...> wrote: > You volunteering? > :-) No :-). I sent 4 patches today that go a long way already. They are basically adaptations of the result of running the 2to3 tool to also work on python 2. The *big* *big* issue left now is bytes versus unicode string. In order to do that I would like to know how you want the API to look like. Do we hand in e.g. folder names as an (UTF-8) string or do we hand in a "bytes" string that will be transmitted to the server as handed to it? Sebastian |
|
From: Piers L. <pi...@ja...> - 2012-02-17 01:55:49
|
On Thu, 16 Feb 2012 12:16:45 +0100, Sebastian Spaeth wrote:
>
> Hi all,
> I hear that at least Ubuntu wants to switch to python3 by default in one
> of the upcoming cycles, and others such as Archlinux already have it.
>
> So I made offlineimap to work with both python2 and python3, but for one
> thing... imaplib2 :-). What is Piers opinion on driving imaplib2 towards
> python3 compatability? I expect that we can make the same code base work
> with both 2 and 3 without *too* much trouble. WOuld patches be welcome
> or is this something you are not interested in?
>
> imaplib2 needs changes in these areas:
>
> 1) Some renamed imports (to lowercase)
> (easy to make work with 2 & 3)
>
> 2) raise Exception, e: --> raise Exception as e:
> (works in python2.6 and 3)
>
> 3) print('moo: %s' % `blah`) -> print('moo: %s' % repr(blah))
> (works in python2.6 and 3)
>
> 4) bytes versus (unicode) strings
> Now that is the big and hairy one. I already have patches for 1-3,
> but this requires some more thinking and work.
> It will mean we have to go through the code and explicitely decide
> when to use unicode strings and when to use "bytes". The upside is
> that this is likely to work in python 2.6 and 3 when done, but it's
> more work that I don't want to waste effort on, if that is not needed.
>
> FYI, standard imaplib in python 3.3 has the conversion done, so we
> can get some inspiration there, although they don't have to deal with
> python 2 backwards compatability of course.
>
> What's your opinion on that?
> Sebastian
I definately think imaplib2 should be converted to run on python3.
Perhaps first do a straight conversion that works, and then try to
make a unified version that runs on all python 2.6+.
You volunteering?
:-)
Piers.
|
|
From: Sebastian S. <Seb...@SS...> - 2012-02-16 11:16:56
|
Hi all,
I hear that at least Ubuntu wants to switch to python3 by default in one
of the upcoming cycles, and others such as Archlinux already have it.
So I made offlineimap to work with both python2 and python3, but for one
thing... imaplib2 :-). What is Piers opinion on driving imaplib2 towards
python3 compatability? I expect that we can make the same code base work
with both 2 and 3 without *too* much trouble. WOuld patches be welcome
or is this something you are not interested in?
imaplib2 needs changes in these areas:
1) Some renamed imports (to lowercase)
(easy to make work with 2 & 3)
2) raise Exception, e: --> raise Exception as e:
(works in python2.6 and 3)
3) print('moo: %s' % `blah`) -> print('moo: %s' % repr(blah))
(works in python2.6 and 3)
4) bytes versus (unicode) strings
Now that is the big and hairy one. I already have patches for 1-3,
but this requires some more thinking and work.
It will mean we have to go through the code and explicitely decide
when to use unicode strings and when to use "bytes". The upside is
that this is likely to work in python 2.6 and 3 when done, but it's
more work that I don't want to waste effort on, if that is not needed.
FYI, standard imaplib in python 3.3 has the conversion done, so we
can get some inspiration there, although they don't have to deal with
python 2 backwards compatability of course.
What's your opinion on that?
Sebastian
|
|
From: Sebastian S. <Seb...@ss...> - 2012-02-16 08:46:24
|
The IMAP specification (RFC 2060, 5.1.3. Mailbox International Naming
Convention) describes how to handle non-ASCII characters in folder
names. It defines a modified UTF-7 encoding...
I have a question with regard to creating new mailbox names.
def create(self, mailbox, **kw):
"""(typ, [data]) = create(mailbox)
does not say anything about encoding, so I had simply passed in a
python2.6 string (e.g. 'INBOX."Make" zine' which looked innocent enough,
and the IMAP debug shows that it actually seems to have worked, as a
listing shows it. Yet the web frontend complains about invalid
foldernames.
Now it could be that this webfrontend simply cannot deal with quotes in
folder names but it raises the more general question, what encoding am I
supposed to use for foldernames? Do I need to pass in the weird UTF7
encoded strings, or should I expect UTF-8 to work just fine? Is this
something that imaplib2 wants to take care off, or do I need to do it?
WOuld it make sense to include a UTF8<->weirdUTF7 conversion helper
function in imaplib2?
Sebastian
|
|
From: Piers L. <pi...@ja...> - 2012-02-06 23:35:15
|
Apologies - I see that Kerry's patch was for imaplib, not imaplib2. Seriously old :-) Piers. |
|
From: Piers L. <pi...@ja...> - 2012-02-06 23:32:24
|
Interesting discussion. As far as I remember, the general advice when
using IMAP is to avoid message numbers for anything except an approximate
guide, and to always use UID when changing any message.
In my user agent, when an EXISTS turns up, I always then do a UID SEARCH ALL.
However, that patch was for an old version of imaplib2, the current
(2.33) version has an ordered list:
def _append_untagged(self, typ, dat):
# Append new 'dat' to end of last untagged response if same 'typ',
# else append new response.
if dat is None: dat = ''
self.commands_lock.acquire()
if self.untagged_responses:
urn, urd = self.untagged_responses[-1]
if urn != typ:
urd = None
else:
urd = None
if urd is None:
urd = []
self.untagged_responses.append([typ, urd])
urd.append(dat)
self.commands_lock.release()
if __debug__: self._log(5, 'untagged_responses[%s] %s += ["%s"]' % (typ, len(urd)-1, dat))
which, presumably, also solves your problem.
Piers.
|
|
From: Sebastian S. <Seb...@SS...> - 2012-02-04 22:14:56
|
On Mon, 30 Jan 2012 19:12:26 -0800, Ross Boylan <ro...@bi...> wrote: > Also, I think in the above scenario the new message will be 5 in a > spec-compliant server. The spec says that sequence numbers must be in > the same order as UID numbers, and that UID numbers must be > any > existing UID for a new message. I think those two imply that 5 is new > (assuming the count was lower than 5 before the 5 exists came in). > > The spec also seems to imply that, supposing there were 4 messages to > start, the server might send > * 7 EXISTS > only, and this would imply that 5,6, and 7 had newly arrived (2.3.1.2 > says > For example, if an untagged "11 EXISTS" is received, > and previously an untagged "8 EXISTS" was received, three new > messages have arrived with message sequence numbers of 9, 10, and 11. Hi Ross, I am by no means an IMAP expert, but I would be very careful in assuming that all IMAP servers are that well behaved as you seem to imply here. The SPEC also says that EXISTS merely "reports the number of messages in the mailbox" and that is very different from the message sequence if you have been deleting/moving/appending a lot around already. So as a rule of thumb, be careful to assume that IMAP servers are sane. Sebastian |
|
From: Ross B. <ro...@bi...> - 2012-01-31 03:14:12
|
On Mon, 2012-01-30 at 19:25 -0700, Kerry Kurian wrote: > On Mon, Jan 30, 2012 at 5:37 PM, Ross Boylan <ro...@bi...> > wrote: > I think that it is not possible to reconstruct exactly which > messages > were added and removed in some circumstances. Is my > understanding > correct? > > > > That is my understanding as well. > If this sequence came back from the server > * 4 EXPUNGE > * 5 EXISTS > then the new message is sequence 5. > > > > Assuming you're in an IDLE, yes. If you got that in response to a UID > FETCH, for example, then it'd mean that 5 messages exist... but not > necessarily that message 5 is new. Thanks for the confirmation, and the patch. However, I'm not sure why you qualify things by "Assuming you're in IDLE" as these kind of responses can come in response to many commands, or in "response" to nothing at all from the client. Also, I think in the above scenario the new message will be 5 in a spec-compliant server. The spec says that sequence numbers must be in the same order as UID numbers, and that UID numbers must be > any existing UID for a new message. I think those two imply that 5 is new (assuming the count was lower than 5 before the 5 exists came in). The spec also seems to imply that, supposing there were 4 messages to start, the server might send * 7 EXISTS only, and this would imply that 5,6, and 7 had newly arrived (2.3.1.2 says For example, if an untagged "11 EXISTS" is received, and previously an untagged "8 EXISTS" was received, three new messages have arrived with message sequence numbers of 9, 10, and 11. We're sort of wandering into general IMAP issues here.... Ross |
|
From: Kerry K. <kk...@gm...> - 2012-01-31 02:25:24
|
On Mon, Jan 30, 2012 at 5:37 PM, Ross Boylan <ro...@bi...> wrote:
> I think that it is not possible to reconstruct exactly which messages
> were added and removed in some circumstances. Is my understanding
> correct?
>
>
That is my understanding as well.
> If this sequence came back from the server
> * 4 EXPUNGE
> * 5 EXISTS
> then the new message is sequence 5.
>
>
Assuming you're in an IDLE, yes. If you got that in response to a UID
FETCH, for example, then it'd mean that 5 messages exist... but not
necessarily that message 5 is new.
> If this sequence came back
> * 5 EXISTS
> * 4 EXPUNGE
> then the new message is sequence 4.
>
>
Correct (again assuming you're in an IDLE). The sequence numbers above the
expunged message decrement immediately. RFC 3501, 7.4.1.
> Since imaplib2 only gives the relative time sequence within a single
> class of untagged response (i.e., EXPUNGE or EXISTS) there is no way to
> tell which of these scenarios happened assuming one recovers the 2
> separate responses.
>
>
So far as I can tell this is also correct. And for what it's worth the
original imaplib behaves the same.
> For my purposes that level of detail is probably not necessary; I can
> just err on the side of caution.
>
> Perhaps imaplib2 should have a callback that would enable tracking the
> exact sequence of messages.
>
You can monkeypatch imaplib2 to keep track of the exact sequence of
untagged responses.
Here's the patch that I applied to imaplib... You should be able to adapt
it for imaplib2:
def patch():
imaplib.IMAP4._append_untagged = _append_untagged
def _append_untagged(self, typ, dat):
##
# The original code
if dat is None: dat = ''
ur = self.untagged_responses
if __debug__:
if self.debug >= 5:
self._mesg('untagged_responses[%s] %s += ["%s"]' %
(typ, len(ur.get(typ,'')), dat))
if typ in ur:
ur[typ].append(dat)
else:
ur[typ] = [dat]
#
##
##
# The new code
try:
self.ordered_untagged_responses.append((typ, dat))
except AttributeError:
self.ordered_untagged_responses = list((typ, dat))
#
##
With all of that said, Piers might be aware of something that we're not...
Cheers,
-K
>
> Ross Boylan
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Imaplib2-devel mailing list
> Ima...@li...
> https://lists.sourceforge.net/lists/listinfo/imaplib2-devel
>
|
|
From: Ross B. <ro...@bi...> - 2012-01-31 00:37:30
|
I think that it is not possible to reconstruct exactly which messages were added and removed in some circumstances. Is my understanding correct? If this sequence came back from the server * 4 EXPUNGE * 5 EXISTS then the new message is sequence 5. If this sequence came back * 5 EXISTS * 4 EXPUNGE then the new message is sequence 4. Since imaplib2 only gives the relative time sequence within a single class of untagged response (i.e., EXPUNGE or EXISTS) there is no way to tell which of these scenarios happened assuming one recovers the 2 separate responses. For my purposes that level of detail is probably not necessary; I can just err on the side of caution. Perhaps imaplib2 should have a callback that would enable tracking the exact sequence of messages. Context: iterating slowly through the messages in a large folder, so that messages might appear or vanish during the iteration. It looks to me as if doing this by message sequence number rather than UID is most natural.(*) The commands are like SEARCH 1:50 <some additional filters> it would be natural to do SEARCH 51:100 <some additional filters> for the next round, but this could miss messages if some were deleted in the interim. Hmm, there is still a problem with a race even if I check the message sequences immediately before the SEARCH, since a message could be deleted in between checking the status and issuing the SEARCH anyway..... (*) Most natural because EXISTS and EXPUNGE use sequence numbers, and because UIDs may in principle have large gaps. The latter implies there could be many searches by UID range that get nothing. Perhaps a more robust approach would be to collect the UIDs of messages at sequence 1, 50, 100, 150, .... at the start, and then fetch by the implied UID range. Ross Boylan |
|
From: Piers L. <pi...@ja...> - 2012-01-30 00:56:37
|
On Wed, 18 Jan 2012 12:37:31 -0800, Ross Boylan wrote:
>
> On Wed, 2012-01-18 at 21:10 +1100, Piers Lauder wrote:
> > On Tue, 17 Jan 2012 14:37:06 -0800, Ross Boylan wrote:
> > >
> > > On Wed, 2012-01-04 at 14:59 +1100, Piers Lauder wrote:
> > > >
> > > > The general timeout in the code is purely for discovering a broken
> > > > socket.
> > >
> > > imaplib2.html says
> > >
> > > > The forth argument sets a timeout for responses from the server, after
> > > > which the instance will abort.
> >
> > Apologies, I was confused about which timeout we were talking.
> >
> > > That conveys the wrong idea, at least to me. I read "abort" as "throw a
> > > an exception (visible to client code)" or possibly "return" if callbacks
> > > are not used.
> >
> > Yes, that timeout triggers this code in _handler() (line 1660 in version 2.31):
> >
> > typ, val = self.abort, 'no response after %s secs' % resp_timeout
> > break
> >
> > which causes any pending commands to abort, and the driver to terminate the connection.
> >
> >
> > On looking at the reader() timeout however, it now seems that the code
> > handling the read(0) case is missing a 'continue'. I'll rewrite it, test it,
> > and post a fix...
> >
> >
> > Piers.
>
> The manual (imaplib2.html) lists timeout in 2 contexts, as an argument
> to __init__ and as an argument to idle. But there seem to be 3 kinds of
> uses of timeout:
> 1) maximum length of time to wait before ending IMAP IDLE.
> 2) how frequently threads do housekeeping, such as checking if they
> should exit.
> 3) how long to wait for a response before triggering an error.
>
> Is the argument for __init__ being used in both senses 2 and 3?
No, just for (3)
> 1) I think I understand, though I'm fuzzy on how to check for
> information returned from IMAP IDLE, and how to determine if I'm back
> from IMAP IDLE because of a timeout or because some information came
> back.
Use: response('IDLE') which returns ('IDLE', ['TIMEOUT']) if the reason
was a timeout, ('IDLE', [None]) for anything else.
> 2) and 3) and their relation to the __init__ argument are not clear to
> me; there seems to be code supporting both behaviors.
Housekeeping timeouts are set by the built-in value of READ_POLL_TIMEOUT,
unless the provided __init__ timeout is less.
Piers.
|
2 messages has been excluded from this view by a project administrator.
