Re: [pyPYME-Giotto] Ancho de banda limitado
Status: Planning
Brought to you by:
pyneo
Menu
▾
▴
Re: [pyPYME-Giotto] Ancho de banda limitado
|
From: Cesar P. V. <ces...@ya...> - 2005-07-13 02:50:56
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Patricio Valarezo wrote: <blockquote cite="mid...@mu..." type="cite">Me olvidaba!, ya has pensado en alguna solución para la interface en redes con anchos de banda limitados ?, podríamos adaptar la misma interface o será necesario crear alguna alternativa mas liviana (si es que existe) o en "modo texto", no tengo experiencia con esto, no se que tan efectiva puede resultar la versión XMLRPC de pyPyme para estos ambientes. En un futuro me gustaría a mi trabajar en alguna versión del POS para dispositivos de mano. <br> </blockquote> ¡Que buena pregunta Patricio! <span class="moz-smiley-s3"><span> ;-) </span></span><br> <br> Si bien no he aun profundizado el análisis del código actual, creo que si la interfaz gráfica tiene localmente acceso a las vistas y controladores no habría problemas de lograr una buena eficiencia de llamadas XMLRPC a otros componentes.<br> <br> Lo coloqué como Historia Épica porque creo que es un tema muy importante al momento de diseñar las vistas y sus funcionalidades. <br> <br> Por ejemplo, si bien puede ser muy comodo para el usuario desplegar la lista completa de clientes para elegir uno de ellos (enfoque comun en aplicaciones con arquitecturas de una y dos capas) puede ser terriblemente ineficiente para n-capas con ancho de banda limitado.<br> Una solución (que por ejemplo implementa SAP) es manejar códigos para ubicar elementos (clientes, facturas, materiales, etc), y si el usuario no sabe el código o no lo recuerda y necesita ayuda para buscar un elemento en particular, presentar primero una ventana de filtro de búsqueda (SAP las llama match-codes) antes de mostrar ningun set de elementos, y siempre que fuera posible limitar la cantidad de elementos a un valor máximo (ejemplo 100 o 1000) a devolver a la interfaz gráfica, avisando al usuario que se devuelve una cantidad limitada del conjunto resultante a su búsqueda.<br> <br> Si usamos el XMLRPC para ejecutar funciones y solicitar acotadas listas de elementos no veo que sea inconveniente para la eficiencia al utilizar bajos anchos de banda.<br> <br> <i>Insisto</i>, es un tema de enfoque de la aplicación desde su comienzo y personalmente creo que vale la pena tenerlo en cuenta. He visto aplicaciones con estructura de dos capas cuya performance empeora notoriamente cuando crece la cantidad de información almacenada por un mal diseño de vistas y controladores. Una pregunta posible sería ¿Como funcionaría este formulario si fuera una página web?<br> <br> Por otro lado, mi opinion es que las versiones para interfaces en modo texto deben tener vistas y controladores específicos, considero muy complejo (por no decir utópico) tratar de unicicar el diseño, porque no quedaría otra alternativa que limitar el potencial de la interfaz gráfica.<br> <br> Éste es un tema importante, tiene muchos enfoques y creo que tendremos que estudiarlo más profundamente cuando llegue su momento, sin dejar de lado el objetivo al realizar la codificación actual. <br> <br> ¿Estas de acuerdo?<br> <br> C.<br> </body> </html> ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar |
