Open gkrcode opened 12 years ago
@ConradIrwin any help ?
Hi @gkrcode,
This was actually intentional. If you're using the listener API you should add a .stopback{}
that cleans up your event senders.
The IDLE
command relies on this behaviour because if it stopped receiving events after you call .stop
, it would never internally hear the "command OK" response in order to be able to .succeed
.
That said, it's pretty confusing... Maybe I should rethink how it is structured.
Thanks @ConradIrwin,
If you're using the listener API you should add a .stopback{} that cleans up your event senders.
I don't get it please share a code sample.
That said, it's pretty confusing... Maybe I should rethink how it is structured.
+1 Looking forward :)
Hi @gkrcode
Have you found the solution for this issue? And one more question to you how can we actually get emails within idle.callback
block? It is giving <struct Net::IMAP::TaggedResponse tag="RUBY0003", name="OK", data=#<struct Net::IMAP::ResponseText code=nil, text="IDLE terminated (Success)">, raw_data="RUBY0003 OK IDLE terminated (Success)\r\n">
but I don't know how can I get actual email from this response?
Hi @nazarhussain , I am no longer using em-imap :(
@gkrcode Do you find any alternate for it? I want to achieve this task, if you can guide me in it. https://github.com/ConradIrwin/em-imap/issues/7
Hi,
Output:
Still Listening Still Listening Stop Still Listening Stop: Callback Still Listening Still Listening Still Listening Still Listening ... ... ...
Listener is active even after stopped, is this normal behavior ?
Thanks