Soporte para IMAP IDLE en ruby ​​

Question

Ok, he estado chupado durante horas. Pensé que net/imap.rb con ruby ​​1.9 soportaba el comando inactivo, pero todavía no.

¿Alguien puede ayudarme a implementar eso? De here, pensé que esto funcionaría:

class Net::IMAP 
    def idle 
    cmd = "IDLE" 
    synchronize do 
     tag = generate_tag 
     put_string(tag + " " + cmd) 
     put_string(CRLF) 
    end 
    end 

    def done 
    cmd = "DONE" 
    synchronize do 
     put_string(cmd) 
     put_string(CRLF) 
    end 
    end 
end 

Pero imap.idle con que acaba de regresar a cero.

Answer 1

¿Estás seguro de que no está funcionando? ¿Has mirado las cuerdas que ha enviado sobre el zócalo?

Después de hacer algunas excavaciones, parece que put_string devuelve nil a menos que tenga habilitada la depuración, por lo que imap.idle devuelve nil.

Así que su método inactivo podría estar funcionando, ya que no está arrojando errores.

¿Eso ayuda a explicar el comportamiento?

Si desea utilizar depuración, utilice Net::IMAP.debug = true

Answer 2

me encontré con esta vieja pregunta y quería resolver por mí mismo. El asker original ha desaparecido, oh bueno.

Aquí se muestra cómo funciona IMAP inactivo en Ruby (esto es genial). Utiliza el bloque citado en la pregunta original y la documentación here.

imap = Net::IMAP.new SERVER, :ssl => true 
imap.login USERNAME, PW 
imap.select 'INBOX' 

imap.add_response_handler do |resp| 
    # modify this to do something more interesting. 
    # called every time a response arrives from the server. 
    if resp.kind_of?(Net::IMAP::UntaggedResponse) and resp.name == "EXISTS" 
    puts "Mailbox now has #{resp.data} messages" 
    end 
end 

imap.idle # necessary to tell the server to start forwarding requests. 

Answer 3

@Peter

que he hecho algunas investigaciones sobre cómo escalar una solución IMAP IDLE. Básicamente, estoy pensando en 2 opciones.

Opción 1: Ejecute un daemon que compruebe el correo de todas las cuentas en un bucle continuo.

Opción 2: abra una conexión IDLE para cada cuenta y reciba actualizaciones.

Dado que mi aplicación se trata de múltiples (tal vez miles o cientos de miles de cuentas) opción 2 parece una imposibilidad. Creo que mi mejor opción es ir con la opción uno, y luego dividir el servidor en varios trabajadores después de alcanzar algún tipo de máximo.

El código/idea básica aquí se ha delineado http://railspikes.com/2007/6/1/rails-email-processing

Answer 4

con Ruby 2.x: la solución es descrito por trozo de código de mzolin aquí: https://stackoverflow.com/a/21345164/1786393

acabo escribió un completo (pero aún borrador) secuencia de comandos para buscar correos no vistos aquí https://gist.github.com/solyaris/b993283667f15effa579

btw, los comentarios son bienvenidos.