[Madrid-pm] Edgar Allan

Bruno brunorc en gmail.com
Mie Sep 12 00:52:25 PDT 2007


Hola

Gracias por tu opinión. He discutado lo que escribiste, y...

2007/9/6, Salvador Fandiño <sfandino at yahoo.com>:
> El rendimiento no lo es todo, el modelo de prefork es mucho mas robusto. Si un proceso muere o se queda colgado o dura demasiado, todos los demas siguen funcionando sin problemas y por lo tanto las peticiones se siguen respondiendo. En cambio en un modelo basado en eventos como el de POE, cualquier error puede parar la aplicacion.

Es verdad. La unica forma de evitar estas cosas es poner más atención
a los errores... usando Design-by-Contract o algo otro. No se puede
[overcome] las faltas del modelo, pero se puede luchar por mejor
calidad del código.

> Ademas, la programacion orientada a eventos es mas complicada, y el codigo que se crea es mas dificil de comprender y por lo tanto de mantener.

Creo que es más cambio de punto de vista. Una véz conocido, el módelo
de eventos parece muy claro. Además supongo, que cuadra muy bien con
cosas de tipo "maquina de estados".

> Otro inconveniente es que la integracion con modulos que hagan IO y que no esten a su vez basados en el mismo modelo de eventos es muy complicada porque requiere hacer un fork (o pseudo-fork) del proceso y ejecutar algun tipo de RPC a traves de un pipe (lo cual ya no es tan eficiente).

Eso también es verdad. Que puedo decir... Sólo se puede hacer un
wrapper para este IO para que funcione con POE. Claro, esto no
facilite el proceso de crear el programa :-D

> En mi opinion, POE esta bien para implementar servicios donde existen interacciones entre las distintas conexiones, por ejemplo un servidor de IRC, pero para un servidor web que ataque una base de datos, no!

En otro lado hay algunas aplicaciones de este tipo realizadas con POE
y la gente esta contenta con efectos. Supongo que no se puede
simplemente decidir "lo haremos con POE" y esperar al exito. Es el
mismo caso que el de OOP. Buen diseño, conocimiento profundo de la
tecnologia dada, experiencia y muchas pruebas - y "last but not least"
habilidad de resignar de la solución nueva si no nos de lo que
expectemos - es el clave.

Muchas gracias por puntos interesantes, un saludo!

Bruno


Más información sobre la lista de distribución Madrid-pm