[IRC-DEV] Re: Petición de comentarios sobre canales masivos

[ROOT]

> Nuevo modo de canal (+D)
>        ----------------------------
>   Este apartado, a petición de jcea, será tratado con más detalle,
> explicando a fondo su modo de funcionamiento.

He pensado un poco mas en el tema y he pensando unas soluciones:

Creo que el modo (<+j clientes (X):segundos (Y)>) que se proponia arriba es
una solucion viable, pero aplicado de otra manera, ejemplo:

    Tenemos a un usuario, Pepe23, este desea entrar en un canal que tiene el
modo +j, ahora si pepe23 entra correctamente porque esta en los parametros
del modo, bien, sino metemos a pepe23 en una especie de lista de usuarios
que desean entrar, y esperamos a que esa lista llege a pepe23, tarde lo que
tarde, si tenemos 500 usuarios mas que desean entrar y metemos uno cada
segundo, pues adelante, enviamos a pepe23 un mensaje indicandole que esta en
espera y que entrara pasados X segundos, y listo. En caso de recibir un part
por parte de pepe23 antes de entrar, simplemente lo sacamos de la lista. En
caso de split, lo unico que pasaria es que los usuarios entrarian mas
moderadamente y sin problemas de entradas masivas. Aunque tiene ciertos
fallos, ya que este modo no soluciona los part masivos...

Otra solucion seria la de usar otro modo un tipo de delayed, pero de otra
manera, establecer un tiempo para que los usuarios vean los joins, supongo
que este modo seria mejor aplicable a usuarios (aunque mas dificil de
implementar), que a canales, por ejemplo:

    Tenemos un usuario llamado Maria. Maria entra en un canal y observa que
cada segundo le caen unos cuantos parts, quits y joins, Maria se esta
volviendo loca de tanto part y tanto join, pues activa el modo +D
(X):segundos, esto lo que hara sera mandarle los mensajes de join, part y
quit al mismo tiempo, pero cada X segundos. Encuentro algunos fallos en este
sistema, si en un segundo maria se vuelve loca, ¿Que pasara cuando reciva
los joins de 100 segundos?, es un tema complejo.

Aunque el modo +D original esta bien, tengo que crititar un
punto:

-El dicho usuario, al entrar en el canal, solo recibe el NAMES de los
usuarios ya visibles, el resto (los de en espera de join) no
salen.

Creo que lo mejor seria cuando el canal recibe +D poner a todos los usuarios
invisibles, marcarlos con el flags de modo de espera, ya que pueden existir
usuarios que esten away y no hablen.

Otra cosa ha comentar seria el que un usuario que no este hablando durante X
tiempo y este como usuario visible ( se podria establecer dentro del modo
+D ) se marque como invisible, ya que se entiende que no esta.

Otra solucion al problemilla seria algo del tipo "vision parcial" pero de
una manera un poco mas delicada, los usuarios que esten dentro no veran nada
mas que a los usuarios con op ( creo que seria poco aconsejable ponerlo a
+v ) y a ellos mismos, pero con la diferencia de que los usuarios podran
leer y recibir los mensajes de los otros, como si el canal estubiera -n y
pudieran recibir mensajes de fuera, aunque la realidad es que estan dentro,
los usuarios con op podran ver la lista completa de usuarios, para poder
realizar el control del canal. Cuando un usuario recibe op, se distribuye un
un join entre todos los usuarios que estan dentro del canal y seguido del
modo +o, creo que es una solucion viable, permite a los usuarios de
conferencias y canales grandes como los de ciudades hablar entre ellos sin
tanto join y part, el unico problema, que no se verian entre ellos, aunque
por experiencia propia puedo decir que cuando buscas alguien con quien
hablar no lo buscas en la lista de nick's.

Saludos.

"No juntes el ocaso y el oriente huyendo al primer paso." de algun libro de
la estanteria. ;)