Access to unsolicited responses

[felinira]

As far as I understand there is currently no public access to unsolicited responses. As server responses to mailbox events are not limited to IDLE it would be very helpful to have access to any responses that have not been handled by any task.

Ordering of these, especially with regards to SELECT and EXAMINE is rather important here. If you switch a mailbox, you'd want to know which mailbox these responses correspond to.

[soywod]

@duesee what are you thoughts on this?

[felinira]

With regards to API, I can personally imagine two approaches off the top of my head, but maybe there are more options:

• API users being able to implement some sort of delegate that automatically gets called with anything not handled by all the other tasks already / significant connection events. I could imagine passing a trait object of some kind that has a few callback methods.
• What everyone else is doing, a channel that just enqueues those responses

The ordering situation can probably be resolved by clearing the channel for any mailbox SELECT, EXAMINE, LOGOUT, ..(?) commands, or by inserting marker messages / calls of some kind informing the client of such changes.

[felinira]

I would really like to have this feature and would be willing to work on this.

Which of the two approaches outlined above would you say fits more with your vision for this project?

Or is there another idea on how to handle this?

[soywod]

I start now the IMAP refactor, so it will be a perfect occasion to take your remarks into consideration. I let you know when I have sth to discuss about.