[Programación] Re: [Programación] figth the power

federico luna programacion@lugro.org.ar
Mon, 12 May 2003 13:45:55 +0200 

Hoy o ma~nana armo un documento un poco mas formal de lo que tengo pensado
del proyecto para discutirlo.

seria una mezcla de mod_fastcgi (por la simplicidad e independencia de
lenguaje) y contenedor de servlet (por el threading y ventajas de correr en
un unico espacio de memoria).

el codigo a full CVS, la doc... MUCHA aunque sea tedioso.
no se si nos conviene poner fechas por ahora. La etapa de creacion es
siempre la mas ostosa y la que mas idas y venidas tiene, ademas como todavia
no existe y nadie nos vanca, no estamos comprometidos con nadie, excepto con
nosotros mismos :). pero eso como prefiera el grupo.

lo que si hariamos es una especie de roadmap que tendra que salir del
documento.

saludos
fedel


----- Original Message -----
From: "Franchi Santiago" <SFRANCHI@pecom.com>
To: <programacion@lugro.org.ar>
Sent: Monday, May 12, 2003 2:26 PM
Subject: [Programación] RE: [Programación] Re: [Programación] figth the
power


Fede,
me parece muy interesante!
cuándo? dónde? y cómo? arrancamos,
la doc y código estaría on line para poder compartirla,
puede que el proyecto necesito un lider para ver de coordinar las tareas,
tendríamos objetivos que cumplir, alguna meta como para comprometernos en el
tiempo??
(espero no haber sonado muy formal, jejeje)
pero conta with me me gusta mucho la idea!!!
saludos,
Tago

> ----------
> De: federico luna[SMTP:fedeml@yahoo.com.ar]
> Responder a: programacion@lugro.org.ar
> Enviado el: Sábado 10 de Mayo de 2003 20:51
> Para: programacion@lugro.org.ar
> Asunto: [Programación] Re: [Programación] figth the power
>
> veo cuatro alternativas de dise~no teniendo encuenta siempre a apache como
> servidor de contenido estatico:
>
> 1) usar un contendor fuera del proceso del apache estilo tomcat
>    1.1 se puede tratar de usar: WARP con el mod_webapp
>    1.2 se puede tratar de usar: AJP  con el mod_jk
>    1.3 se puede hacer un protocolo propio y su implementacion
>
> 2) usar un contenedor en el proceso del apache estilo mod_jserv
>    2.1 no me parece una alternativa buena (poco escalable, y demasiado
> webserver dependiente, y creo que los demonios del apache se harian muy
> pesados para levantar los .so), pero nos permitiria centrarnos en el
> funcionamieto del contenedor.
>
>
> paso el link de los conectores de jakarta-tomcat.
>
> http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors
>
>
> alguien tiene idea de las diferencias que hay entres WARP y AJP para poder
> pesar mejor las alternativas?
> Por lo que vi como WARP es mas nuevo el codigo fuente del mod_webapp
> parece
> mas sencillo.
>
> Y no nos alvidemos de caucho!!!, alguien tiene idea como funciona mas
> menos?
>
> saludos
> .fedel
>
>
> ----- Original Message -----
> From: "Sebastián D. Criado" <scriado@ciudad.com.ar>
> To: <programacion@lugro.org.ar>
> Sent: Sunday, May 11, 2003 12:39 AM
> Subject: [Programación] Re: [Programación] Re: [Programación] Re:
> [Programación] figth the power
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Me has desasnado en varios puntos en lo referente a lo que quieres hacer
> y
> me
> > parece una excelente iniciativa de proyecto para desarrollar.
> > Cuales te parece que serían los pasos a seguir del punto que decís "
> podriamos
> > empezar por una version simple"?
> > Es decir, busco como sería la mejor forma de empezar.
> > Mis conocimientos en C++ como sabrás son muy pocos, pero estoy dispuesto
> a
> > aprender y colaborar.
> > Sería interesante que elaboraramos la idea principal de diseño. Si te
> parece,
> > nos podemos poner a verla el viernes en la reunión a modo de un pequeño
> > bosquejo.-
> >
> > Saludos.-
> >
> >
> > El Sábado 10 Mayo 2003 12:43, federico luna escribió:
> > > > > che que les parece la idea de hacer una implementacion
> > > > > "semejante" a los servlets de sun pero para c++
> > > > > quitandole todo el vigor de la programcion OO de la
> > > > > que uno es victima en java?
> > > > >
> > > > > las premisas que tengo pensadas serian:
> > > > >
> > > > > - la ejecucion de los procesos (request, response,
> > > > > etc) en entorno controlado (sobre todo para manejar
> > > > > los SIGSEGV)
> > > > >
> > > > > - funcionmaniento como modulo de apache.
> > > > >
> > > > > - las api expuestas tendrian que ser parecidas a las
> > > > > servlet API de sun siempre pero siempre tratando de
> > > > > aprovechar la programcion de templates de c++ (esto es
> > > > > discutible y paradojico, ya lo se)
> > > >
> > > > bastante  :-)
> > > >
> > > > > - configurar el entorno de desaroollo tiene que ser
> > > > > sencillo e implementar un servlet mas sencillo aun.
> > > >
> > > > Un Bonobo Object?
> > >
> > > no. no tendria sentido usar CORBA o una arquitectura rigida de
> componentes
> > > para un webserver.
> > > Este punto requerira:
> > > * un buen dise~no modular para la facil configuracion
> > > * sacar snapshot bastantes completos para minimazar las molestias de
> que
> el
> > > soft no anda por problemas de dependencias, (osea todo lo contrario a
> > > bonobo).
> > > * hacer transparente la definicion de una clase C++ al echo de ser un
> > > servlet.
> > >
> > > > > - implementacion de servlets como shared objects (???)
> > > > >
> > > > > - filosofia UNIX y GNU (minimalista)
> > > >
> > > >  Pequeñitas cosas juntas, hacen cosas grandes
> > >
> > > si y todo lo demas ;)
> > >
> > > > > Se que existen por ahi un par de proyectos como estos
> > > > > se podrian analizar y reutilizar codigo, sumarme a
> > > > > esos proyectos no me interesa por un cuestion de
> > > > > filosofica.
> > > > >
> > > > > saludos
> > > > > fedel
> > > >
> > > > lo pensas como un conjuto de Objects?
> > >
> > > ???
> > >
> > > > no se por que me suena a los viejos CGI en C :-)))
> > >
> > > en que sentido?
> > >
> > > cada ciclo request/response de un CGI corre en un proceso aparte del
> > > servidor http, en un implementacion de servlets los procesos son
> ejecutados
> > > por thread, este suele ser el argumento para justificar el uso de
> servlets
> > > (el ahorro de instanciacion de nuevos procesos, fork(), que suelen ser
> > > bastante mas costoso que crear un thread).
> > > Pero hay otro punto bastante importante, el echo de que TODOS los
> > > request/response se ejecuten en un mismo espacio de memoria permite al
> > > webserver y la aplicacion mantener informacion de estado (variables de
> > > applicacion, variables de session, pooling, etc)
> > > Otra ventaja es la posibilidad de implemtar la funcinalidad del
> forward
> de
> > > las API de los servlets que es una alternativa muy util al redirect
> (HTTP
> > > 302), a la hora de implementar un patron MVC con signos de
> performance.
> > >
> > >
> > > yo lo estoy pensando por el lado de un proceso independiente al
> webserver
> > > (suele llamarse contenedor), este es el que procesaria los
> request/reponse
> > > en threads y devolveria los resultados al webserver.
> > > La conexion entre este proceso y el apache seria realizada por un
> modulo
> de
> > > apache que trasferira los request al proceso contenedor (via TCP/IP,
> fifos,
> > > shared mem lo que sea), este lo ejecuta, y responde. (algo similar al
> > > mod_jk o warp de tomcat, nada estrafalario)
> > >
> > > se copan??? o les parace demasiado userland?
> > >
> > > podriamos empezar por una version simple de un thread por request por
> > > cservlet.
> > > eso nos ahorraria la adminstracion de threads para los request.
> > >
> > > saludos
> > > fedel
> > >
> > >
> > > _______________________________________________
> > > Programacion mailing list
> > > Programacion@lugro.org.ar
> > > http://www.lugro.org.ar/mailman/listinfo/programacion
> >
> > - --
> > - --
> > Sebastián D. Criado - scriado@ciudad.com.ar
> > L.U.G.R.o - http://www.lugro.org.ar
> > GNU/Linux Registered User # 146768
> > - -------------------------------------------------------------------
> > "Si el Universo fuera un programa estaría hecho en C, y correría sobre
> > un sistema UNIX"
> >                                                    Anónimo.
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.2 (GNU/Linux)
> >
> > iD8DBQE+vX+p8hmHQ8ZCg0IRAgfQAKCwbhirGdFgw+tbLrWt3zWmJx118ACbBSQu
> > SE9iQvhfrkqH6UZKE18gp6k=
> > =qJTf
> > -----END PGP SIGNATURE-----
> >
> >
> > _______________________________________________
> > Programacion mailing list
> > Programacion@lugro.org.ar
> > http://www.lugro.org.ar/mailman/listinfo/programacion
>
> _______________________________________________
> Programacion mailing list
> Programacion@lugro.org.ar
> http://www.lugro.org.ar/mailman/listinfo/programacion
>