-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Diego Roig Seigneur escribió: > Esteban A. Maringolo escribió: >> Guillermo Schwarz escribió: >> >>> Implementé algo parecido en Java y salió espectacular. Me demoré 2 >>> semanas en que se viera algo y de ahí en adelante puedo hacer cosas que >>> no se pueden hacer en Struts y todo sale increíblemente simple.
>> Y como implementaste las continuations? >> > No se si las habrá implementado o no, pero lo que algunos hacen es > "simular" las continuations usando excepciones (en Java, las Runtime > Exceptions, que no requieren declaración en la firma de los métodos). > Acá hay mas información: > http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html > Ojo, no esperen algo elegante ;) Simplemente un "hack" para simular el > efecto de las continuations (con algunas limitaciones). Hubo una discusión en unos blogs de javeros, sobre si el soporte debería incluirse a nivel de JVM, y lo que entendí que dieron como explicación fue que el estilo de Continuations si bien era "bonito" (asi de despreciativo), no era un buen estilo de programación, y era un Go To llevado a la web. >>> Estuve leyendo el otro día que SeaSide tiene problemas, pero no entendí >>> la explicación. ¿Alguien tiene más información al respecto? >>> >> >> Si das un poco más de información acerca de "qué" problema, tal vez te >> podamos ayudar. >> > No se a que problema se refiere, pero me IMAGINO que SeaSide podría > tener problemas de escalabilidad por el enfoque que tiene con las > continuations. Cada interacción de un cliente genera un completo > snapshot del stack, por cada click que hace. Si hay cientos o miles de > usuarios accediendo a la aplicación (no necesariamente en forma > simultanea) esto puede hacer crecer el uso de recursos mas de lo > conveniente. Este "caché" de stack no es infinito, y es parametrizable a n niveles. Por lo que se puede tunear dependiendo del tipo de aplicación. Con el resurgimiento de AJAX, las aplicaciones/páginas web cada vez necesitan menos de las continuaciones, dado que no hay tanto salto de páginas, y algunas cosas se hacen directamente en la página (con dialogos modales in-situ [*]) El mayor problema (que dependiendo del caso puede ser solucionado), es la serialización de sesiones, para hacer balanceo de carga donde una sesión puede ser atendida por más de un servidor. Las sesiones no se pueden serializar, ya que los stacks y todo eso (contextos, bloques de callbacks, etc) no son serializables. De todos modos, el mismo A. Bryant lo dijo, lo más probable es que en el futuro lo qué más diferencie a Seaside sea el uso de callbacks y su forma de trabajo, y las continuations caigan en desuso. [*] Ver caso www.flickr.com, dabbledb.com > Por lo que ví, SeaSide es excelente para sistemas que van a ser usados > por pocas personas (de análisis, de soporte a las decisiones, etc), pero > no lo veo para sistemas "transaccionales" donde van a ser accedidos por > muchos usuarios para tareas relativamente simples. > Seguramente le pifio en mas de alguna apreciación. Si alguien lo usó > para sistemas de este tipo (transaccionales), por favor que comente su > experiencia. No tengo experiencia práctica, pero creo que puede ser utilizado para alta carga, pero no como esta ahora, ya que hay mucho round-trip por cada solicitud de "página". Y por cierto, asi como Smalltalk no es SmallTalk, Seaside no es SeaSide ;-) Saludos. - -- Esteban -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) iD8DBQFEmIWsdPDJq/J5MioRAk++AKCetu4OtgQEJLnLgl031CSIzCEqgQCfYJEL HLMOXKh1qA37TtPkCosJgY8= =nNBT -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ Ha recibido este mensaje porque está suscrito a Grupos de Google "clubSmalltalk" grupo. Si quiere publicar en este grupo, mande un correo electrónico a [email protected] Para anular la suscripción a este grupo, envíe un mensaje a [EMAIL PROTECTED] Para visualizar más opciones, visite este grupo enhttp://groups.google.com/group/clubSmalltalk -~----------~----~----~----~------~----~------~--~---
