Hexchat: Agregue soporte para el módulo de reproducción ZNC

Creado en 24 ago. 2014 · 13Comentarios · Fuente: hexchat/hexchat

El módulo de reproducción avanzado [ 1 ] hace posible que los clientes de IRC eviten la reproducción repetitiva indeseada del búfer. Los clientes de IRC pueden solicitar al módulo que envíe una reproducción parcial del búfer a partir de un determinado momento.

Además, el último maestro ZNC [ 2 ] tiene soporte para búferes de consultas persistentes [ 3 ]. Un cliente puede optar por mantener los búferes de consultas hasta que se cierren explícitamente en la GUI. Esto también se puede hacer más fácilmente a través del mismo módulo de reproducción para evitar respuestas no deseadas de ZNC [ 4 ].

Junto con el complemento mymsg [ 5 ], estas dos características brindan la experiencia de IRC con ZNC a un nivel completamente diferente.

EDITAR: Se eliminaron las referencias a la implementación de ejemplo rápida y sucia que ya no existe. La bifurcación donde estaba almacenada ya no existe.

[1] http://wiki.znc.in/Playback
[2] https://github.com/znc/znc/pull/598
[3] http://wiki.znc.in/Query_buffers
[4] https://github.com/znc/znc/pull/620
[5] https://github.com/TingPing/plugins/blob/master/HexChat/mymsg.py

PD. Considere hacer que el cliente sea capaz de recibir mensajes de sí mismo sin un complemento mymsg adicional.

bounty enhancement

Fuente

jpnurmi

👍4

Comentario más útil

¿Alguna noticia sobre el progreso de esto?

Avamander en 31 may. 2016

👍6

Todos 13 comentarios

Casi diría que esto pertenece a un complemento. Parece bastante simple, pero es mucho más específico de ZNC que el tiempo del servidor.

TingPing en 25 ago. 2014

@jpnurmi Mind revisando https://github.com/hexchat/hexchat/tree/znc

EDITAR: Después de pensarlo, creo que el complemento debería almacenar una única marca de tiempo por servidor. No hay razón para mantener uno por contexto con el uso actual.

TingPing en 5 sept. 2014

¡Parece prometedor! Sin embargo, he estado jugando con él y noté que algo sale mal con las marcas de tiempo. A menudo se reproducen mensajes de canal que ya he visto. Parece que si me desconecto de inmediato y luego me vuelvo a conectar, obtengo la misma reproducción nuevamente.

jpnurmi en 5 sept. 2014

También me di cuenta de que no podía haber nada en el complemento. ¿Notó problemas similares en su sucursal WIP?

TingPing en 5 sept. 2014

Parece funcionar con wip / playback. Algunos pensamientos aleatorios que podrían ayudar a resolver el problema:

una marca de tiempo por conexión es suficiente
el módulo de reproducción agrega tiempo de servidor a todos excepto a los mensajes de límite
debe almacenar la última marca de tiempo de cualquier mensaje visto, no solo privmsg
tenga cuidado de no tomar la marca de tiempo de 001 antes de enviar el comando de reproducción inicial o no obtendrá la reproducción :)

jpnurmi en 5 sept. 2014

una marca de tiempo por conexión es suficiente

Ya lo hice localmente, el problema aún existe.

TingPing en 5 sept. 2014

Parece que si me desconecto de inmediato y luego me vuelvo a conectar, obtengo la misma reproducción nuevamente.
También me di cuenta de que no podía haber nada en el complemento.

Tuve una breve desconexión y reconexión con ZNC y me envió un mensaje en un canal que sucedió durante el período de desconexión (confirmado por otro cliente). Esto fue _sin_ soporte de reproducción. Quizás vuelva a intentar los envíos no sincronizados desde la conexión rota a la nueva. Entonces, si HC hubiera pedido soporte de reproducción, probablemente habría recibido ese mensaje dos veces.

Arnavion en 13 ene. 2016

¿Alguna noticia sobre el progreso de esto?

Avamander en 31 may. 2016

👍6

@jpnurmi , 404 en sus enlaces. :llorar:

marsjaninzmarsa en 16 jul. 2016

Tomé otra oportunidad con un complemento que parece funcionar mejor: https://github.com/TingPing/plugins/blob/master/HexChat/playback.lua

TingPing en 25 jul. 2016

Tuve una breve desconexión y reconexión con ZNC y me envió un mensaje en un canal que sucedió durante el período de desconexión (confirmado por otro cliente). Esto fue sin soporte de reproducción. Quizás vuelva a intentar los envíos no sincronizados desde la conexión rota a la nueva. Entonces, si HC hubiera pedido soporte de reproducción, probablemente habría recibido ese mensaje dos veces.

¿No es esto sólo un búfer ZNC estándar? Nada que ver con el módulo [[reproducción]] para znc.

mB-PiBox en 15 oct. 2016

@TingPing su playback.lua más reciente funcionó bien para mí, aunque todavía observo la reproducción de mensajes que ya he visto también. Gracias, aunque esto es mejor que nada :)