🚀 go-pugleaf

Juanjo wrote:
> 
> Antonio Larrosa escribió en mensaje <384E5DB7.66C19FF7@arrakis.es>...
> >Supongo que no es una solución perfecta si quereis hacer el lector
> >para otros toolkits que no tienen estas facilidades. De todas formas,
> >os recomiendo que empeceis usando estas librerias, porque al menos podreis
> >hacer una primera versión del programa _muy_ rápido, y luego, podreis
> >hacer otras versiones una vez que ya tengais algo funcionando.
> 
> >Hasta luego, y suerte con el programa.
> 
>    Gracias, ¿y no habría posibilidad de usar los kioslaves en gnome?, he
> visto con un "ps" que son
> procesos independientes.
> 

Por ahora son procesos independientes aunque se está pensando en cambiar
a lib. dinámicas. De todas formas, si los usas en GNOME, no tendrías el
sistema de comunicación entre tu aplicación y el kioslave, con lo que en la
práctica, me parece que no puedes usarlos.

De todas formas, esa es "una" de las ventajas de programar en KDE :-)
igual que los kioslaves hay _muchas_ otras ventajas.

> También queremos abarcar, una versión para Windows, usando gtk.
> 

¿ Una versión para Windows ?
No estás ayudando :-)
¿Así haces que Linux prolifere ?
La verdad, me parece absurdo plantearse hacer un programa para "eso" y darlo
gratuitamente. Especialmente cuando los usuarios de Windows ya tienen el
Outlook y no creo que muchos cambien. Además, ya sabes el refrán : "quien
mucho abarca ... "

>    El proyecto lo tenemos pensado de la siguiente manera:
> 
>    Dos grandes módulos: "back-end" y "front-end", el backend, abarca casi
> todo el programa, las comunicaciones, la gestión de las carpetas de usuario.
> etc. y es independiente del interfaz gráfico que se utilice.
> 
>     El front-end, es dependiente del interfaz que se utilize, curses, linea
> de comandos, qt, gtk, motif, etc, y debe ser lo más simple posible en lo que
> respecta al código.
> 

La verdad, hacer _un_ programa para _un_ toolkit ya es suficientemente
complicado como para hacerse _bien_.
Como ya dije, yo recomiendo que empeceis haciendo un programa, si la cosa
va bien y tiene exito (cosa que espero), entonces lo portais a otros toolkits,
si no, al menos tendreis un programa que funciona y que se puede usar.
Lo que me temo que pase es que os pongais unos objetivos muy amplios y
el proyecto se pare simplemente en la fase de diseño. No sería la primera
vez que veo que sucede y espero que no sea el caso.

Además, el hacer que un programa se integre en el escritorio cuando comparte
código con otros toolkits es algo dificil. Por ejemplo, usando KDE, teneis
automáticamente soporte de Unicode en la aplicación (pensad que en Japón, Rusia,
etc. también quieren leer el correo con vuestro programa :-) ). Si quereis
que el programa se ejecute en ncurses, el "back-end" debe ser independiente
y ya empiezan a surgir conversiones de unos tipos de datos a otros (neutrales
respecto al toolkit) que usa el back-end => El código se hace menos legible =>
=> El programa evoluciona mas lento.

>   Los dos módulos son ejecutables diferentes, y se comunican entre ellos
> mediante un mecanismo IPC sin especificar todavía, colas de mensajes, corba,
> tcp/ip, etc. Me comentan que podría utilizarse
> TCP/IP, pues de esta forma un mismo programa podría estar ejecutandose de
> forma distribuida en dos máquinas con dos OS diferentes. ¿corba utiliza por
> debajo TCP/IP?, ¿Qué tal es su seguridad?.
> 

En KDE ya sólo se usa CORBA cuando no hay otra herramienta mejor. Todas las
comunicaciones las hacemos a través del servidor DCOP (Desktop COmmunication
Protocol). Esto permite como dices usar un programa de forma distribuida.
Manejar toda la interfaz de un programa desde un script en Python, Perl, 
e incluso desde un script en "otros" sistemas operativos, comunicación
entre programas de manera facil y rápida, etc.

Si quieres mas info sobre como se usa DCOP, mira en un tutorial que he hecho
sobre programación en KDE, está en http://www.arrakis.es/~rlarrosa/kde.html
Todavía lo tengo que ampliar bastante ( y escribir en inglés :-) ), pero la
comunicación con DCOP ya está explicada.

Básicamente es:
dcopclient->send("IDdelaAplicaciónRemota", "NombreDelObjeto",
					"mifuncion(int)", parametros))

Y ejecuta la función "mifunción" del objeto con nombre "NombredelObjeto" en
otra aplicación, muy rapidamente (mucho mas rápido que con CORBA) y con un
código mucho mas legible y sencillo (como estás viendo).

>      A parte de eso, la parte de comunicaciones IPC, de la parte frontend,
> debe ser una librería de enlace dinámico y ser un API en C, para que pueda
> ser usada por otros lenguajes, y por otras aplicaciones.
> 

Supongo que puedes hacer un wrapper alrededor de las kioslaves, pero ni
quedaría bonito, ni el código sería legible, ni sería interesante cuando
puedes usar los kioslaves directamente. Por ejemplo, tienes que tener mucho
cuidado con hacer que no se bloquee el programa mientras está resolviendo
el nombre del servidor o cargando el correo/news. 

Esto ya está solucionado en los kioslaves, y no creo que reinventar la rueda
sea la solución.

>     Por ejemplo, un CGI que permita a un usuario leer correo desde la web,
> al estilo Hotmail, teniendo el servidor Apache instalado. O un proceso que a
> una hora se conecte a la red y se baje el correo
> y las news de forma automática.
> 

Como digo, esto se puede hacer usando DCOP, con un script (incluso en bash !)
que se comunique con el programa y llame a determinadas funciones especificadas
como interfaz de la aplicación.


****
> --
> Antonio Larrosa Jimenez
> Student of Mathematics
> antlarr@arrakis.es        larrosa@kde.org
> http://www.arrakis.es/~rlarrosa
> Klein bottles for rent -- inquire within.
> 

Por favor, ten cuidado cuando respondas, porque aunque mi firma aparezca
ahí, yo no he escrito el mensaje al que estoy respondiendo :-/
Como comprenderás aunque tu nombre esté en el From:, puede haber
malentendidos, cosa que no me hace gracia (si te gusta la frase,
copiala, pero no la firma completa ! :-) )

Hasta luego,

--
Antonio Larrosa Jimenez
Student of Mathematics
antlarr@arrakis.es        larrosa@kde.org
http://www.arrakis.es/~rlarrosa
Klein bottles for rent -- inquire within.