[IRC-DEV] Empieza el BrainStorming sobre "chan2"

[Jesus Cea Avion]

> Ya en este caso, podríamos configurar dos cadenas de flags por
> defecto, tanto para nicks no registrados en nick2, como nicks
> registrados en nick2 pero sin registro en dicho canal (autovoz en
> caso de nick registrado y nada en caso contrario, por poner un 
> ejemplo).

Yo esto lo he pensado, pero si se usa eso, el tema se complica bastante.
Habría tres categorías de usuarios: Usuarios sin +r, usuarios con +r
pero sin registro en el canal, y usuarios con +r y con registro en el
canal.

Según mi diseño inicial, para cada canal registrado habría dos matrices
de bits. Una matriz indica los modos OBLIGATORIOS y otra matriz indica
los modos PROBIHIDOS. Estos modos incluyen tanto modos de canales como
permisos del estilo "puede invitar", "puede pasar op", "puede cambiar
modos", etc. Eso supone unos 8 bytes por canal registrado. Según eso,
cuando un usuario cambia de modos, la evaluación de modos nuevos es muy
sencilla:

modos_actuales =
      modos_viejos_con_cambios OR OBLIGATORIOS AND NOT PROHIBIDOS

Esto no requiere ningún acceso a la BDD, una vez generados
"OBLIGATORIOS" y "PROHIBIDOS".

Con tu propuesta, es necesario acudir a la BDD cada vez que un usuario
solicita un cambio de modo. Aunque su flexibilidad sería ideal, no sé
hasta qué punto se usaría en la práctica, y la complejidad del código y
la demanda de CPU sería muchísimo mayor.

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz