Hola Ale, José, lista:

> De: Alejandro F. Reimondo [mailto:aleReimondo@...]


> Por otra parte, la solución de conectar images de forma
> transparente preserva la actividad de tus objetos;
> pero disminuye la seguridad (cosa lógica y natural,
> pero no aceptada por quienes están acostumbrados
> a que el software siempre "funcione igual" y quienes
> entienden que un sistema no puede "sorprender"
> ni fallar)

El asunto es el enfoque que se le de, y que objetivos se tienen.
El enfoque abierto, en el cual al ser todo más transparente, tambien es más
fragil (y más orgánico) no me parece apropiado siempre, pese a que sea el
que más me gusta.

Muchas veces pensé en que el repositorio de objetos sea otro smalltalk,
grabando los objetos sobre el image, y con una interfaz para brindar los
objetos a quienes lo requieran. Teniendo en este "smalltalk-server"
funcionando en un equipo con las mejores condiciones de estabilidad que
pueda darle a una app, osea, un sist op bien configurado y estable,
alimentación ininterrumpida, seguridad, etc.

No se como implementa GemStone el almacenamiento, pero sería interesante al
menos tener una idea :-)

Volviendo al tema, no te parece que muchas veces es necesario que el sistema
funcione "siempre igual", o por lo menos que sea lo más predecible posible
(hago algo y no tengo que rezar para que mañana esté).

Obviamente es menos "natural" este enfoque, ya que es poner energía en que
algo se mantenga "constante", cuando lo unico constante es el cambio, y por
lo tanto lo predecible es solo una tendencia y no una realidad.

No se que experiencias tienen, y en particular cuando se trabaja con
información (objetos, datos, etc) histórica y relacionada.

> o hacerla después de tener el sistema completo.
> (la decisión de hacerla en paralelo o después, depende de la
> experiencia del
> equipo de trabajo... si tienen poca, mejor hacerla lo mas tarde posible).

Okey, en esta estoy entonces :-)


Saludos

--
Esteban.