Ah, para clarificar. >> Che, si es esto
esto = "tener proxies y mandar mensajes remotos a objetos sin perder la identidad del objeto", por ejemplo... >> a lo que Mariano se referia, no nos olvidemos de >> GemStone que hace no se, 25 años que esta con su base de objetos >> (esencialmente se puede ver como una imagen compartida entre N otras >> imagenes, con transacciones). Si eso eso = "resolver el problema de distribucion de mensajes a objetos distribuidos de manera razonablemente general, como por ejemplo lo hace GemStone"... >> es lo que aca se describio como >> "trivial", desde ya que de ninguna manera es trivial ese problema. >> Trivial podra ser una primera aproximacion a la serializacion, pero >> literalmente "objetos distribuidos" asi como en GemStone, ni ahi. Andres. 2010/10/11 Angel Java Lopez <[email protected]>: > Hola gente! > > Ah! Yo, por lo menos, nunca mencione GemStone (que alguien bueno de Sugar > (Smalltalk Users Group de Argentina) me comento en los noventa, el bueno de > Leandro Caniglia, recuerdo su implementacion en Luchetti, que recuerde). > > Lo que me gustaria (tengo codigo, pero no tengo test, asi que nada de > publicado ahora), es: > > anObject msg: par1 .... > > y anObject sea un proxy local, que deriva a un objeto residente en otra > maquina ese mensaje. El programador puede haberlo creado local (como para > probar su algoritmo en una sola maquina) o puede haberlo creado en otro nodo > de una red. En los casos de uso que tengo en mente, el programador sabe que > hay un costo en eso, asi que no esta conversando con esos objetos a cada > milisegundo. Es mas: te doy una tarea, despues, llegado el caso, en algun > momento, por otro canal, recibire una respuesta. > > Tambien quiero implementar: > > anObject msg: par1 ... > > y que anObject por abajo, derive el mensaje a uno, a todos, o a algunos de > otros objetos, remotos o locales. > > Y algo ortogonal a todo eso, que tengo implementando, pero tendria que > unirlo con lo de remoting: > > anObject msg: par1 ... > > que anObject reciba el mensaje, y lo atienda en su propio thread. Recibe el > mensaje, lo coloca en una cola en memoria, y lo atiende en su propio thread, > cuando este disponible. El objeto que envie el mensaje sigue su camino. Esto > permite implementar algoritmos en paralelo, sin el tema "te envio algo, y te > espero a que termines para seguir yo". > > Interesante el paper que enviaste, lo conocia, pero no lo recordaba. Ya lo > mando a twitter. > > No entendi si "si es esto a lo que Mariano se referia", y "Si eso es lo que > aca", digo, no entendi "si esto" en la primera frase se refiere a lo mismo a > lo que se refiere "si eso", en la segunda. > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com > http://twitter.com/ajlopez > > 2010/10/11 Andres Valloud <[email protected]> >> >> Che, si es esto a lo que Mariano se referia, no nos olvidemos de >> GemStone que hace no se, 25 años que esta con su base de objetos >> (esencialmente se puede ver como una imagen compartida entre N otras >> imagenes, con transacciones). Si eso es lo que aca se describio como >> "trivial", desde ya que de ninguna manera es trivial ese problema. >> Trivial podra ser una primera aproximacion a la serializacion, pero >> literalmente "objetos distribuidos" asi como en GemStone, ni ahi. >> >> Ah, hablando de esto, hace poco encontre este articulo que me parecio >> interesante. >> >> http://www.rgoarchitects.com/Files/fallacies.pdf >> >> 2010/10/11 Angel Java Lopez <[email protected]>: >> > Hola gente! >> > >> > Interesante la discusion del Thread "Blog", pero tambien algo se fue por >> > las >> > ramas... Cambio de titulo en este mensaje. >> > >> > Estuve agregando objetos distribuidos a mi pet project [1], quedo algo >> > asi: >> > >> > http://pastie.org/1213856 >> > >> > Tengan encuenta que no tengo libreria de clases de base, asi que tengo >> > que >> > comenzar desde nil subclass:... ';-) >> > >> > Puedo: >> > >> > - Levantar un servidor (tecnologia Remoting .NET), en nodo A. >> > - Levantar un cliente remoto a ese servidor, en nodo B. >> > - Definir una clase en nodo B. >> > - Exportar su definicion de B a nodo A. >> > - Ejecutar desde nodo B algo en nodo A. >> > - Evaluar en nodo A y devolver el objeto serializado (contemplando >> > grafos >> > con ciclos, repeticion de objetos, etc..) a B. >> > >> > Me falta evaluar en nodo A y que el resultado quede en A, viajando a B >> > una >> > especie de proxy, de tal manera que invocando a ese objeto en B, se >> > ejecute >> > el mensaje en nodo A. >> > >> > Mi idea es que si B devuelve un objeto a A, ese resultado viaja >> > completo. >> > Sino, definiria algo como >> > >> > ^host asProxy: result. >> > >> > Tendria que escribir post, pero por ahora, tengo esto para mostrar. >> > >> > [1] http://code.google.com/p/ajtalk >> > >> > Nos leemos! >> > >> > Angel "Java" Lopez >> > http://www.ajlopez.com >> > http://twitter.com/ajlopez >> > >> > >> > >> > -- >> > To post to this group, send email to [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > >> > http://www.clubSmalltalk.org >> >> -- >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> >> http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > > http://www.clubSmalltalk.org -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
