Wrapper para descentralizar pygtk.

[dvilla en gmx.net]

Hola:

Nosotros estamos haciendo también algo del estilo. En nuestro caso, la
aplicación cliente, que corre en una iPaq, invoca un método de un objeto CORBA
remoto y obtiene un .glade. Después la aplicación cliente renderiza el
formulario y recoge los resultados que se envián al servidor de nuevo invocando
otros métodos. 

Si aparte de recoger datos, el GUI requiere de interacción con el servidor, el
cliente puede invocar métodos remotos como callbacks de los widgets.

Ventajas:
- Este modelo permite tener GUIs completamente dinámicos; el servidor puede
modificar el .glade que sirve, en base a sus propias circustancias y añadir o
eliminar opciones de los menus o listas. En cada petición los formularios pueden
cambiar si fuese necesario. Por otra parte, si el cliente tiene el formulario
anterior, puede comprobar con un CRC o nº de secuencia si el .glade que tiene el
servidor ha cambiado y solicitarlo sólo en ese caso.

- El cliente sólo conecta con el servidor para pedir el formulario y enviarle de
vuelta los datos con lo que el cliente puede quedar fuera de covertura entre
tanto sin que afecte al resultado. Esto es ideal en redes adhoc en las que el
cliente se mueve y pasa de un AP a otro, y por tanto puede quedar sin
conectividad en ciertos momentos.

- no hay que tocar gtk ni hacer wrappers.

- gracias a CORBA, los clientes y los servidores pueden estar escritos en
diferentes lenguajes y correr en arquitecturas distintas.

- se integra directamente con .NET. Con Remoting.CORBA todo objeto CORBA es
automáticamente un objeto .NET estándar. [1]

- mucho más rápido que cualquier servicio web. No hay que generar, transportar
ni parsear XMLs.

- no es dificil de depurar ya que que si se hacen llamadas "in-proc" se puede
tracear el código del servidor en el momento en que se hacen las llamadas
"remotas".

Saludos.

[1] http://remoting-corba.sourceforge.net/


El Wed, 18 Feb 2004 19:35:21 +0100
"Ernesto Revilla" <aerd en retemail.es> escribió:

> Hola,
> 
> La idea del 'Terminal GTK' es bastante curiosa. Si lo quieres, yo también creo
> que deberías ver pyro, como indica Luis.
> 
> Nosotros queremos correr applets en el cliente (formularios interactivos).
> Para conectar el servidor con el cliente ahora mismo hemos implementado
> nuestro propio protocolo, basado en XML-RPC, que básicamene crea ObjectProxies
> para objetos del servidor en el cliente y manda identificadores a través de
> XML-RPC, como cadena de caracteres y lo convierte de nuevo en identificadores
> de objetos en el servidor. Por supuesto, también se traducen (recursivamente)
> todos los parámetros. XML-RPC no trata None, ni funciones que no devuelvan
> valor (lo que es lo mismo que el None). Para que no se accede a
> identificadores que no sean válido en el servidor, se mantiene un mapa en el
> servidor, para cada sesión. (Por si se cuelga el cliente, se elimina la sesión
> después de un timeout.)
> 
> Aunque no recuerdo todos los detalles, no era demasiado difícil de escribir,
> pero sí un tanto trucolento, y difícil de depurar.
> 
> Si quieres ver detalles, puedes mirar en el código fuente de
> http://gruppy.sf.net mediante cvs.
> 
> Saludos, Erny
> 
> 
> 
> ----- Original Message ----- 
> From: "Luis Rodrigo Gallardo Cruz" <lrgallardo en interservice.net>
> To: "La lista de python en castellano" <python-es en aditel.org>
> Sent: Wednesday, February 18, 2004 6:29 PM
> Subject: Re: [Python-es] Wrapper para descentralizar pygtk.
> 
> 
> On Wed, Feb 18, 2004 at 10:39:22AM +0100, Pepe Aracil wrote:
> > ... simplemente se cambiaría el
> > "import gtk" por "import remote_gtk". y ¡Ya está! ya tendríamos la
> > aplicación servidora en la cual  reside la lógica y todas las acciones sobre
> > pygtk se transmitirían la aplicación cliente.
> 
> Hasta donde entiendo, lo que quieres es invocar los metodos de un
> objeto desde otra máquina, especificamente los de un(os) objeto
> GTKWindow. Quizá el proyecto Pyro te sirva:
> 
> http://pyro.sourceforge.net/
> 
> 
> > Lo que haría el modulo "remote_gtk" es simplemente re-implementar las clases
> > de pygtk de forma que cuando se cree un objeto, se acceda a una propiedad o 
> > se ejecute un método, esta acción se transmita a la aplicación cliente que
> > es donde realmente se interactúa con gtk. Lo mismo se aplica a la inversa
> > cuando salte un evento en la aplicación cliente, este se enviara a la
> > aplicación servidora para que se ejecute la función pertinente.
> > 
> > Este sistema requiere mucho menos ancho de banda que una conexión por X
> > y permitiría la creación de  servidores de aplicaciones con una interface 
> > mucho mas adaptada para cierto tipo de aplicaciones que la web.
> 
> Decidir si usa más o menos ancho de banda que X es un poco dificl a
> priori. Yo creo que tendrías que experimentar. El problema es que para
> invocar metodos remotos tienes que enviar los objetos que son sus
> argumentos y eso puede ser pesado.
> 
> > Bueno pues nada que parece que esta noche de insomnio me he rayado un 
> > poco. :-D
> > 
> > Si alguien está interesado en emprender un proyecto como este, que me lo
> > haga saber.
> 
> Pues lo malo es la falta de tiempo :-)
> 
> -- 
> Rodrigo Gallardo
> PGP Key ID:  ADC9BC28 
> Fingerprint: 7C81 E60C 442E 8FBC D975  2F49 0199 8318 ADC9 BC28
> 
> 
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es
>