David Woodhouse wrote:
On Thu, 2003-03-13 at 00:34, Alexey Melnikov wrote:
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
That is indeed almost
On Tue, 2003-03-18 at 20:16, Alexey Melnikov wrote:
Also do you really have to return MODSEQ messageset for each SEARCH and
SORT? You're just returning the search results twice. Why not add the MODSEQ
into the untagged reply itself? ie. * SEARCH 1 2 4 10 (MODSEQ 123). Since
client
On Wed, 2003-03-12 at 16:49, Mark Crispin wrote:
On Wed, 12 Mar 2003, David Woodhouse wrote:
After all, although Evolution is taking 10 seconds to open certain
folders at the moment because it's re-downloading flags, it doesn't
actually _need_ all of those flags
Right. So why does it
On Wed, Mar 12, 2003 at 05:45:25PM -0700, Alexey Melnikov wrote:
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
The functionality you propose can be build
On Thu, 2003-03-13 at 15:42, Timo Sirainen wrote:
On Wed, Mar 12, 2003 at 05:45:25PM -0700, Alexey Melnikov wrote:
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the
On Thu, Mar 13, 2003 at 04:04:56PM +, David Woodhouse wrote:
I mentioned earlier. Instead of storing it for each message, I'd use my
existing transaction log file to remember last few changes. MODSEQ would be
last_MODSEQ + position in log file. MODSEQ of messages not in log file
would
On Thu, Mar 13, 2003 at 06:18:43PM +0200, Timo Sirainen wrote:
If you do this, you'll need to fix up the case where there's a single
client and it's the only one making changes to the folder.
I'm not sure what you mean.
OK, I now I get it :) Yes, it would prevent client from caching the
On Tue, 2003-03-11 at 22:56, Mark Crispin wrote:
That's not the right view. You should instead have how can I build a
good client within the context of IMAP, without expecting the existing
IMAP world to add facilities to enable me.
That's how I _started_. I looked at the way UIDs allow me to
On Wed, 2003-03-12 at 06:58, Eric A. Hall wrote:
I'm not trying to start a religious war here, but how much work would it
really be to have a protocol extension which allowed the client to request
flags which have changed since time. It seems that all of the difficulty
would be in the
on 3/12/2003 2:42 AM David Woodhouse wrote:
On Wed, 2003-03-12 at 06:58, Eric A. Hall wrote:
I'm not trying to start a religious war here, but how much work would it
really be to have a protocol extension which allowed the client to request
flags which have changed since time. It seems that
On Wed, 12 Mar 2003, Eric A. Hall wrote:
I'm going to assume you meant something sane when you said time, of
course :)
Uh, heh, I meant time alright. Specifically have the server return a
timestamp whenever a folder is closed, and let the client cache it.
We're digressing somewhat. Yes
Hi Eric,
--On Wednesday, March 12, 2003 12:58:55 AM -0600 Eric A. Hall
[EMAIL PROTECTED] wrote:
| I'm not trying to start a religious war here, but how much work would it
| really be to have a protocol extension which allowed the client to request
| flags which have changed since time. It seems
On Wed, 12 Mar 2003, David Woodhouse wrote:
After all, although Evolution is taking 10 seconds to open certain
folders at the moment because it's re-downloading flags, it doesn't
actually _need_ all of those flags
Right. So why does it need to download all of them? Note that the SEARCH
on 3/12/2003 5:38 PM Steve Hole wrote:
The answer -- the bigger the mailbox and the lower the transaction rate
into the mailbox, the bigger the win. If the mailbox was small or
had a high transaction rate (lots of expunged and new messages) then it
wasn't that much of a win.
A number
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
The functionality you propose can be build as a small extension to CONDSTORE
(and yes, other people already
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
The functionality you propose can be build as a small extension to CONDSTORE
(and yes, other people already
On Thu, 2003-03-13 at 00:34, Alexey Melnikov wrote:
Please, have a look at draft-melnikov-imap-condstore-10.txt. Your timestamp is
called modseq (modification sequence) in the draft. FLAGS-VALIDITY is called
HIGHESTMODSEQ in the document.
That is indeed almost precisely what I was looking for.
Hi,
On 11 Mar 2003 10:20:22 +, David Woodhouse [EMAIL PROTECTED] wrote...
Consider the case where the following happens, in this order:
1. Client SELECTs a mailbox.
2. Mail arrives.
3. Client issues 'IDLE' command.
AFAICT nothing in RFC2177 states that the server
On Tue, 2003-03-11 at 10:39, Mark Keasling wrote:
There is no race condition. When the client sends the idle command, it
is telling the server to send notification about new mail as it arrives.
Since new mail has already arrived prior to the initiation of the IDLE
command, the server should
Hi,
On 11 Mar 2003 10:48:52 +, David Woodhouse [EMAIL PROTECTED] wrote...
On Tue, 2003-03-11 at 10:39, Mark Keasling wrote:
There is no race condition. When the client sends the idle command, it
is telling the server to send notification about new mail as it arrives.
Since new mail
On Tue, 2003-03-11 at 11:41, Mark Keasling wrote:
But you didn't say 'MUST' in capitals :)
Okay, I've had to dig out RFC2060 and thumb through it.
Here is the relevant text...
... A server MUST send mailbox size updates automatically
if a mailbox size change is observed
On Tue, 2003-03-11 at 12:21, Timo Sirainen wrote:
I've been thinking that server could send STATUS-replies whenever it
notices new mail in mailboxes. Maybe a STATUS-WATCH (mailboxlist) or
similiar command for that. Or that configuration could even be done at
server side so it might not even
On Tue, Mar 11, 2003 at 01:59:26PM +, David Woodhouse wrote:
Well, even though the server is already permitted to send unsolicited
STATUS 'replies', the client would need to know that the server _will_
do so, hence that the client doesn't need to keep polling.
Well, yes. The reason I want
On Tue, 2003-03-11 at 15:09, Timo Sirainen wrote:
On Tue, Mar 11, 2003 at 01:59:26PM +, David Woodhouse wrote:
Well, even though the server is already permitted to send unsolicited
STATUS 'replies', the client would need to know that the server _will_
do so, hence that the client
On Tue, 11 Mar 2003, David Woodhouse wrote:
I've already switched from wu-imapd to Courier, because I objected to
wu-imapd trawling through megabytes of each of my project archive
folders, checking the status of each message to see if it's unseen, when
it had done precisely the same thing one
On Tue, 11 Mar 2003, David Woodhouse wrote:
By 'ctime' I meant the inode ctime on the underlying file system, for
the inode of the mbox file.
I know what ctime is.
When configured to 'check for mail in all folders' Evolution is issuing
a LIST command, and then for each mailbox listed it's
On Tue, Mar 11, 2003 at 03:58:55PM +, David Woodhouse wrote:
But I'm still the wrong end of a 64K ISDN line and even now, with
negligible time actually taken by the _server_ the round-trip time for
40-odd STATUS commands is enough to annoy me.
That could be fixed by sending all the STATUS
On Tue, 2003-03-11 at 17:15, Mark Crispin wrote:
On Tue, 11 Mar 2003, David Woodhouse wrote:
By 'ctime' I meant the inode ctime on the underlying file system, for
the inode of the mbox file.
I know what ctime is.
Sorry :)
I was just confused because you seemed to be saying there was a
On Tue, 2003-03-11 at 17:30, Timo Sirainen wrote:
That could be fixed by sending all the STATUS queries to server at once.
That's not really going to help. If I send all the STATUS queries to the
server at once, it'll go off and ignore me for a while, while it does
them all for me. It could be
David Woodhouse wrote:
When configured to 'check for mail in all folders' Evolution is issuing
a LIST command, and then for each mailbox listed it's issuing a STATUS
command.
I assume that you are using check for mail in all folders because the
server is directly delivering new mail to folders
On Tue, 2003-03-11 at 17:52, twk wrote:
I assume that you are using check for mail in all folders because the
server is directly delivering new mail to folders other than the inbox.
Otherwise this option (which I believe Evolution turns on as a
default...ack) is unnecessary.
Yes, that's
On Tue, 11 Mar 2003, David Woodhouse wrote:
Evo _does_ generate unusually high traffic to the server. You select a
mailbox and it'll refuse to display _anything_ until it's got _all_
headers for _every_ mail in that mailbox. You select a mail with a small
text/plain body and a _huge_
On Tue, 2003-03-11 at 20:28, Mark Crispin wrote:
On Tue, 11 Mar 2003, David Woodhouse wrote:
Evo _does_ generate unusually high traffic to the server. You select a
mailbox and it'll refuse to display _anything_ until it's got _all_
headers for _every_ mail in that mailbox. You select a mail
On Tue, 11 Mar 2003, David Woodhouse wrote:
I'm trying to take the view IMAP is too limiting; how can
we fix it.
That's not the right view. You should instead have how can I build a
good client within the context of IMAP, without expecting the existing
IMAP world to add facilities to enable
on 3/11/2003 4:56 PM Mark Crispin wrote:
Have you noticed that Pine *does* completely cache within a session? As
long as you don't give up the session, Pine will never re-fetch the same
data.
I'm not trying to start a religious war here, but how much work would it
really be to have a
35 matches
Mail list logo
