[Programación] Re: [Programación] Re: [Programación] figt h the power

[federico luna]

> > 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