[Solar-general] Re: [Organizarnos] Para desarrollar aplicaciones bajo GNU/Linux: un cimarron que no es amargo

[Martin Olivera]

Reenvio mensaje de Fede:

 --- Federico Heinz <fheinz en vialibre.org.ar> escribió:
> Amigos,
> 
> les quiero contar de un sub-proyecto de PAPO que Vía
> Libre está llevando
> a cabo, y que creo que es de interés para todos los
> que quieren
> desarrollar aplicaciones administrativas bajo
> GNU/Linux. Para los
> impacientes: se llama "cimarrón", y lo pueden bajar
> de la página de PAPO
> (http://papo.vialibre.org.ar), por cvs anónimo (para
> tener una versión
> más actualizada y con más funcionalidad --- esto
> está avanzando muy
> rápido) con el comando:
> 
>         cvs -z3 -d
> anoncvs en savannah.nongnu.org:/cvsroot/papo co
> cimarron
> 
> (para que esto funcione, tienen que tener ssh
> versión 2 instalado, y en
> algunas distros, van a tener que exportar la
> variable de entorno CVS_RSH
> con el valor 'ssh', es decir "export CVS_RSH=ssh")
>  
> Mientras lo bajan, les cuento la historia: cuando
> empezamos PAPO,
> salimos a buscar un ambiente en el cual basar el
> desarrollo. Teníamos
> una serie de requerimientos, el más fuerte era que
> tenía que ser
> multi-todo: multi-capas, multi-UI (gráfico,
> caracter, web),
> multi-plataforma, multi-base de datos... Dimos
> muchas vueltas, nos dio
> la impresión de que GNU Enterprise cumplía con
> nuestros requisitos, y
> comenzamos el desarrollo basándonos en ese proyecto.
> 
> Con el paso del tiempo, lamentablemente, comenzamos
> a descubrir
> problemas serios con nuestra elección: para ser
> multi-todo, GNUe había
> sacrificado una serie de cosas que consideramos
> importantes, pero por
> sobre todas las cosas, tenía un problema de diseño
> que nos complicó
> mucho la vida: es un solo aparato monolítico que
> abarca desde la UI
> hasta la conexión SQL: tiene su lenguaje de
> descripción de pantallas (en
> XML), su application server (que sólo está diseñado,
> y falta para la
> implementación), su interfaz a la base de datos... y
> no se puede
> mezclar. Si vas a hacer GNUe, tenés que agarrar
> todo, no podés usar sólo
> un pedazo, o reemplazar un pedazo por algo que te
> guste más.
> 
> Al final, la versión 0.2 de PAPO está ahí, funciona
> en varios lados,
> pero no estamos conformes. Por un lado, la
> presentación del sistema es
> muy espartana, pero más que nada, lo que hay debajo
> de capot no nos
> satisface: la lógica de negocios está muy atada al
> GUI, la falta del
> servidor de aplicaciones para "sostener" nos forzó a
> encontrar
> soluciones bastante ad-hoc y muy procedurales. Como
> consecuencia,
> decidimos que obviamente GNUe no es lo adecuado por
> nuestro proyecto, y
> buscamos con qué reemplazarlo.
> 
> Encontramos algunas cosas muy piolas, que antes no
> habíamos visto (o aún
> no estaban). Decidimos seguir con Python, como
> lenguaje, por
> considerarlo de los menos "atemorizadores" para
> novatos, y encontramos
> un sistema de persistencia objeto/relacional para
> Python (stand-alone o
> bajo Zope) inspirado en el Enterprise Objects
> Framework de Apple. Se
> llama Modeling (http://modeling.sf.net/), y se los
> recomiendo tres
> veces. Es un muy buen trabajo de Sébastien Bigaret
> que hace un muy buen
> balance entre magia y simplicidad (es decir: no
> invierte enormes
> cantidades de magia en resolver cosas que se pueden
> arreglar fácilmente
> con un poquito de esfuerzo de parte del
> programador). Sébastien además
> es un líder de proyecto de esos de los que a uno le
> gustaría que hubiera
> más: considerado, atento, capaz, muy buen
> comunicador.
> 
> Para application server encontramos tantos
> distintos, que decidimos
> postergar la decisión para más adelante, sabiendo
> que al menos siempre
> tenemos la posibilidad de usar a Zope como opción de
> fallback.
> 
> Nos queda el tema del UI, y allí no encontramos nada
> que nos
> satisficiera. No queríamos pegarnos a GTK o a QT, y
> ni siquiera a una
> interfaz gráfica. Por lo demás, la mayoría de los
> widget sets que andan
> dando vueltas por ahí están diseñados para manejar
> una interacción muy
> compleja con el usuario: la idea es que con ellos
> uno pueda escribir
> *cualquier* aplicación. Pero los programas
> administrativos por lo
> general tienen un modelo de interacción muy simple,
> y la funcionalidad
> "excesiva" de los widgets lleva a que el programa
> deba ser más complejo
> que lo que hace falta. En realidad, a algunos nos
> gustó Entity, pero ese
> proyecto ha muerto para renacer como Oblingua en
> algún momento del
> futuro, pero no sabemos cuándo.
> 
> Ahí nace, entonces, Cimarrón. Se trata de un juego
> de widgets abstracto,
> que define cosas como campos de entrada de texto, de
> fechas, checkboxes,
> etc, sin decir *nada* acerca de su apariencia en
> pantalla, y un modelo
> de interacción simplificado. Una aplicación
> desarrollada usando Cimarrón
> crea instancias de esos widgets, los que a su vez
> crean instancias de
> los widgets concretos con los que interactúa el
> usuario. El chiste está
> en que los widgets concretos pueden estar
> implementados en cualquier
> cosa. Actualmente los tenemos implementados en GTK y
> GTK2, como
> ejemplos, y se pueden hacer las clases
> correspondientes para que la
> aplicación funcione usando QT (debería ser fácil), o
> curses (más
> laburo), o...
> 
> Todavía no tenemos un formato XML para describirlo
> estáticamente, ni un
> constructor de GUI gráfico, sino que hay que
> construir las instancias
> usando código, pero ninguna de estas cosas debería
> ser complicada.
> 
> A esta altura ya debe haber bajado (no es muy
> grande). No hay
> documentación formal aún, pero estamos trabajando en
> mejorar la
> consistencia de los comentarios y los docstrings en
> el código, y hay
> ejemplos de cómo hacerlo andar (algunos pueden
> requerir que instalen
> Modeling y PostgreSQL). Los invito a que lo prueben,
> le peguen, lo
> critiquen... ¡y sobre todo contribuyan! :-)
> 
> Abrazos,
> 
> 	Fede
> 
> PS: ¿Por qué "cimarrón"? Bueno, lo que pasa es que
> está pensado
> siguiendo el pattern "Model-View-Controller",
> también conocido como
> "MVC". Se nos ocurrió que un nombre lindo para algo
> que implementa MVC
> podía ser "MaVeriCk"... pero lamentablemente no
> fuimos los primeros en
> pensarlo: hay como cinco proyectos que se llaman
> así, y no quisimos
> repetir el fiasco de Firebird, pero "maverick" se
> traduce al castellano
> como "cimarrón", y buscándolo en el diccionario nos
> encontramos con que
> tiene varias acepciones:
> 
>         cimarrón, -rrona
>         
>         1 adj. [animal doméstico] Que huye al campo
> y se hace montaraz.
>         -
>         2 adj.-s. Amér. Esclavo que huía buscando la
> libertad. -
>         3 adj. [animal] Salvaje, por oposición al
> domesticado; [planta]
> 
=== message truncated ===

> ATTACHMENT part 2 application/pgp-signature
name=signature.asc
 

=====
SOLAR Software Libre Argentina
http://www.solar.org.ar

------------
Los mejores usados y las más tentadoras 
ofertas de 0km están en Yahoo! Autos.
Comprá o vendé tu auto en
http://autos.yahoo.com.ar