Hello Norman, > > > > > This difficulty has been compounded by the fact that I have found > > difficult to find the right way to inform the processor that a new > > message was created. > > Why this ? I mean this should get handled via the MailboxListener > stuff. Can you give me some more informations about your problems ?
It just took me a while to figure that part out because it's hidden inside the hierarchy of . I think I have it figured out though. > > > > In my opinion, the UidToMsnConverter is a mistake. Caching UIDs > > should be left as an exercice to the store implementor if they want > > it, or be provided as an optional service. This layers has made > > debugging difficult for me. The getMsn method returning -1 has also > > masked some problem from my view while debugging, problem which were > > only found by observing the client IMAP trace and debugging the IMAP > > processor. > > Well the "caching" is mostly done to make sure the UID to MSN mapping > will be correct while have the mailbox selected. Not sure how you > would handle this otherwise.. I had neglected paying attention to the "Message Sequence Number Message Attribute" in the IMAP standard. Now that I understand UidToMsnConverter is really about that, I need to check my stuff again with that new information in mind. The high level view of my problem happens at the arrival of a new message inside a selected mailbox. The IMAP client asks for message UIDs which are not known by my store. The UID it asks could not possibly have been generated by me as far as I know. I first though this discrepancy was due to a intermediate layer that I did not fully understand, but I might have been mistaken by a long day of debugging. Now, I still think getMsn returning -1 is a problem. If the processor asks for a mail which the UidToMsnConverter doesn't know, it returns -1 and that number happens to be sent down the wire in a FETCH response. This confuses the IMAP client which usually disconnects from the server. If you don't happen to have a verbose IMAP trace running, the problem might be totally invisible by the client. I would prefer a big fat exception be thrown on unknown message than this. F-D --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
