[Sitio] Drupal import/export API, clientes de blogs y sintaxis wiki

[Alexandre Oliva]

On Feb 19, 2007, "Antonio Ognio" <antonio at linux.org.pe> wrote:

> Me indicaron que quizás lo que se acerca un poco es el modulo que
> ofrece una API para importar y exportar datos disponible aqui:

> http://drupal.org/node/67043

Esto puede parecer útil, pero realmente no es.

Considera que yo hago download de toda la base de datos porque
necesito hacer un cambio global (como ya hice muchas veces desde que
empezé el uso de svnwiki)

Escribo un script, hago los cambios, y hago upload.

Oops, todos los otros cambios que si hicieron mientras mis cambios
eston perdidos.


Cualquier solución que no implemente alguna forma de locking, o al
menos verificación atómica de otros cambios, presenta este problema.


Por cierto debe ser *posible* crear primitivas checkout/update y
commit en Drupal, con resolución de conflictos cuando necesario,
tornándolo un servidor/repositorio de control de versiones así como un
servidor Subversion, CVS, etc.

Pero como esto no es el foco de Drupal, esto nunca será su objetivo
principal.  La representación "nativa" de la base de datos de Drupal
no está construida para posibilitar este caso de uso.

Entonces, veo que la solución más adecuada para este caso de uso es la
adoptada por svnwiki: el repositorio SVN es la base de datos, la
representación "nativa", y la conversión a html, sea después de
commits, sea on-the-fly, es solo un módulo de presentación.

Lo mismo se podría decir de la base de datos de Drupal, pero su base
de datos interna no es apropiada para este caso de uso, y no veo razón
para inventar otra interfaz a bancos de datos para les dar apariencia
de repositorio de versiones.  SVN ya lo hace.

> Uno de los usos que menciona es el de la gestión de contenidos
> offline. [...]

> Otra sugerencia interesante que me dio el usuario sepeck del canal irc
> fue la de usar un cliente de blogging estandar para editar contenido
> localmente y subirlo a Drupal. Esto no equivale a usar Emacs pero es
> una alternativa a editar en el browser.

El problema mayor no es necesitar editar en el browser.  Yo puedo
hacer cut&paste en el browser, editar en Emacs, y despues hacer
cut&paste nuevamente para el browser.  Esto es muy inconveniente, pero
es posible, e es lo que hago hoy.

El problema mayor es la distancia entre la representación interna de
datos y la representación utilizada para cambios.  Esto es lo que,
para mi, inviabiliza cambios globales a través de scripts.

> Quizás combinando el módulo de importación y el de sintaxis de wiki se
> puede encontrar una solución que permita seguir usando Drupal.

Francamente, aún no veo razón para seguir usando Drupal, buscando
formas imperfectas de superar sus limitaciones para nuestro caso de
uso, cuando hay otras herramientas que son perfectas para él.

A mi suena como un caso de buscar hacer pasar triángulos por hoyos
cuadrados, y no triangulares, porque le gustan más hoyos cuadrados.

La pregunta no es "¿qué hacer para seguir usando Drupal?".  La
pregunta es "¿cuál es la mejor herramienta para el sitio de FSFLA?"

Por cierto es posible que lo que es una terrible inconveniencia para
mi (como el uso que hago de Drupal hoy) sea deseable para otros, y lo
que es una funcionalidad indispensable para mi (el uso que hago de
svnwiki) sea inútil para otros.

Pero ¿hay funcionalidades en Drupal que lo hagan indispensable para
algunos de nosotros?  ¿Hay algo en svnwiki que lo haga una terrible
inconveniencia para alguien?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}