[Previo por Fecha] [Siguiente por Fecha] [Previo por Hilo] [Siguiente por Hilo]
[Hilos de Discusión] [Fecha] [Tema] [Autor]On Wed, 2003-11-26 at 17:25, felipe.molina wrote:
> Que tal lista
>
> Que piensan de esto:
>
> En una ocasion en una conferencia escuche que los cgi's tenian su tiempo
> contado que el futuro era plataformas com net, J2EE, etc.
>
> Mi opinion en cuanto a este punto y hablando de java solamente es que es
> algo lento; las pruebas que yo he realizado es mas rapido un php y me
> imigino que en perl mucho mas (para accesar bd via web)
>
> Esto va en ralacion a que estamos conociendo perl para emigrar un
> sistema de php a perl y la cuestion es ¿valdra la pena seguir trabajando
> con una tecnologia que ya esta muriendo? o sera mejor desarrollar con
> J2EE?
>
> Descarto net por que creo que java le lleva varios pasos adelante.
Los CGIs, los clásicos programas ejecutados cada vez que el servidor
recibe una solicitud, e independiemente del lenguaje en que estén
escritos (lease perl, c, shell, java, etc) nacieron para tareas
puntuales y de poca monta, pero no creo que estén destinados a morir,
pues siempre existirá ese nicho.
Cualquier sistema en Web que se respete requiere el uso de otras
tecnologías.
Si bien J2EE es una de ellas, y muy popular, es efectivamente la más
ineficiente (lease "se arrastra"), pues las "ventajas" de java se
acaban en cuanto lo usas en el servidor.
De los progresos recientes en PHP no puedo opinar, pues lo abandoné por
las limitaciones que le encontré en su momento. ;-)
Lo que si te puedo recomendar ampliamente es usar perl, ya que lo están
conociendo, y si su proyecto es grande aprovechen para no adquirir
vicios, van algunas recomendaciones:
- No hagas CGIs, usa mod_perl!
- No uses CGI.pm!
- Separa por completo el código (la lógica de tu aplicacion) del
diseño (CSS y HTML)
No lo uses para imprimir HTML, deja que los diseñadores hagan
su trabajo.
(No hagas cosas del estilo: print "<TABLE><TR><TD>$dato"... )
Usa algún motor de templates, hay muchos
- De las bases de Datos
Usa conexiones persistentes cuando se requiera.
Si la base es pequeña y/o no requires demasiada concurrencia usa
MySQL, en caso contrario utiliza PostgreSQL. En cualquier caso
usa DBI, para que puedas cambiar de RDBMS.
Si no requieres toda la funcionalidad de SQL, DB de Berkeley es
_mucho, mucho_ mas eficiente.
- Estudia los detalles del protocolo HTTP (cosas como cuándo POST,
cuándo GET o HEAD) y sé amable con los cachés:
No quieras generar todo el contenido cada vez. (El contenido
dinámico tiene lapsos de vida muy distintos!)
Respeta los GETs condicionales.
Pon a tus entidades headers completos: Content-Length, Expires,
etc.
- No te pongas a parsear a mano los "requests", usa las bibliotecas.
- El contenido estático (imagenes, estilos, etc.) mantenlo por
separado y preferentemente despachalo con, por ejemplo, TUX.
- No uses cookies para mantener las sesiones, usalas para las
"preferencias" y configuración de los usuarios.
- Implementa algún sistema de autentificación centralizada, separado
de las bases de datos de la aplicación.
Saludos.
--
Salvador Ortiz Garcia <sog en msg com mx>
Matías Software Group
_______________________________________________
Ayuda mailing list
Ayuda en linux org mx
Para salir de la lista: http://mail.linux.org.mx/mailman/listinfo/ayuda/