There is no "refresh". The concept is meaningless in IMAP, particularly
for number of messages and other mailbox state. Mailbox state is always
pushed from the server to the client.
You need to deal with the underlying cause. If the client state is
"stalled", then your code is in some way failing to update client state
properly. Probably, either your implementation of IDLE is incorrect, or
(as suggested in my previous message) you incorrectly expect state to
cross from one session to the other without per-session notification.
There is nothing that you can do to "refresh" client state.
I understand your desire for a simple palliative. In this case the
palliative is neither simple, nor effective, nor existent. I am not
hiding some secret technique from you. You can continue searching for
such, but will continue to be frustrated until you change course and go
about it the right way.
Last, but not least, IDLE is not push. In many servers IDLE causes worse
battery consumption, and doesn't deliver instantaneous notification for
all that (the delay can be up to 1 minute in UW and Panda). If your
customers expect push, they will be very disappointed with a product that
does IDLE.
Apple does not do IDLE on iPhone and iPod Touch at all. RIM does IDLE
between BIS and the IMAP server, but does real push (not IDLE or even IMAP
at all) to the BlackBerry. Put another way, BIS runs interference and
prevents the battery consumption problems caused by IDLE.
I am sorry if this free advice is not to your liking. I tell people what
they need to know to solve their problem, which is not necessarily they
want to hear.
On Fri, 13 Mar 2009, Shawn Walker wrote:
Mark,
c-client as a IMAP client now does support IDLE, multi-threaded (for IDLE and
because the Windows application is a multi threaded application) and support
asynchronous sessions to be able to handle IDLE. This was done so that the
application can use c-client for the IMAP client communication. The code was
modified to be able to handle that. I know you are not a fan of IDLE, but
our customers wanted the "push" feature to get e-mails instantaneously
instead of the client polling the server X minutes (or seconds if the client
want to be aggressive about it).
Everything is working great except for one small issue.
The client has two IMAP sessions opened in two different threads (in a single
process, multi-threaded). The reason is out of my control due to how the
windows application was written (but that's another discussion for another
day).
From the process IDLE thread, the client got the untagged IMAP responses, the
client end the IDLE with the DONE command and then the client sent a NOOP,
but the message cache is still staled.
I'm not here to debate what is "wrong" in your view with using IDLE,
multi-threaded application, using more than one IMAP connections to the IMAP
server. I just want a solution to how to get c-client to refresh it's
message cache properly without having to disconnect and reconnect to the
server.
Regards,
Shawn
Mark Crispin wrote:
On Fri, 13 Mar 2009, Shawn Walker wrote:
The application has multiple threads with 2 connections to the IMAP
server. One of them is for IDLE.
This application does not use c-client to do IMAP client. c-client does
not support client-end IDLE.
Presumably, by "thread", you mean threads in a process as opposed to
message threads.
UW imapd does not run multi-threaded; each IMAP session has its own
process. Nor does the c-client library use threads.
So, whatever is threading and using IDLE does not seem to have anything to
do with c-client or imapd.
When something happen on the IDLE thread, the server send a list of
untagged IMAP commands to the client of what happened.
The server sends untagged IMAP responses, not commands.
The IDLE thread see that it need to update a folder, but the IDLE thread
has two messages the UID of 100 and 101 (an example). But, UID 101 is
doesn't exist anymore, but UID 102 is on the server. So, the IDLE thread
request the message cache for UID 102 but c-client doesn't know about 102
in it's message cache due that it only know of UID 100 and 101 and return
with a NIL. Hence, the message cache is stale.
This makes no sense, so I have to guess what you are talking about.
My guess is that client has two IMAP sessions open. One of those sessions
did an IDLE command that notified the client of new messages. You expected
that the other session would instantaneously know about those new messages,
even though that session had not yet been notified.
That is not the way IMAP works. Each IMAP session has its own independent
state, and is notified of new messages independently.
Why do you have two IMAP sessions open on the same mailbox? That, by
itself, suggests that you are not using IMAP properly. No well-written
application should need more than one IMAP session open to a mailbox at a
time.
The only way that I can get the message cache to throw away it's message
cache is to disconnect from the server and then reconnect to the server
and then the message cache will have UID 100 and 102.
It there is a change in the mailbox state, the session will be notified of
that fact as part of executing a command. State changes do not magically
transfer from one session to another.
What I need is to tell c-client to refresh it's message cache to have UID
100 and 102. Is there a c-client call that I make that will do that?
You need to execute a command. If nothing else, a NOOP command.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
--
Shawn Walker
Senior Software Developer
Bynari, Inc.
6220 Gaston Ave, Suite 403
Dallas, Tx 75214
http://www.bynari.net
swal...@bynari.net
(800) 241-1086
(214) 350-5772 X29
(214) 352-3530 fax
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
