Re: [Imap-uw] Best way to refresh the message numbers of a stale folder?
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
Re: [Imap-uw] Best way to refresh the message numbers of a stale folder?
I never thought you were hiding anything about some secret code to refresh the message cache. Just asking if you have any suggestions to get the message cache updated. I never implied IDLE is push, why I used quotes around push. I understand the logic behind IDLE. What we are doing is giving the users the impression that the messages is being pushed but it's not. IDLE just notify the client something happened, go figure it out. I'll just figure a way to get the message cache update properly. Shawn Mark Crispin wrote: 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
Re: [Imap-uw] Best way to refresh the message numbers of a stale folder?
On Fri, 13 Mar 2009, Shawn Walker wrote: I'll just figure a way to get the message cache update properly. The way to figure it out is to fix the bug in your code. I identified the bug. In case you missed it: 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. -- 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
[Imap-uw] Best way to refresh the message numbers of a stale folder?
What is the best way to refresh a stale folder state? I'm having a issue with one thread that contain a stale UID in it's cache. I know that I could disconnect from the server and reconnect, but is rather expensive to have to wait for the server/client to connect. Regards, Shawn ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Best way to refresh the message numbers of a stale folder?
On Thu, 12 Mar 2009, Shawn Walker wrote: What is the best way to refresh a stale folder state? I'm having a issue with one thread that contain a stale UID in it's cache. I don't know what you mean by a folder state, much less a stale folder state or the act of refreshing such; nor what message numbers of a stale folder may be; nor what a thread that contains a stale UID in its cache may be. I know that I could disconnect from the server and reconnect, but is rather expensive to have to wait for the server/client to connect. I'm even more bewildered reading this sentence than I am the previous one. Please explain what behavior that you are seeing, and what behavior you expect in its place. Maybe I'm going senile; I haven't a clue as to what you're talking about. -- 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
