Ugh, not SOAP.  Unless you plan to talk to non-smalltalk entities.
Smalltalk already deals with objects serialized binarily and deals
with the case that the save was done on a machine with a different
byte ordering scheme.  I would think that system could be exploited to
dump Smalltalk data raw across a link (including running methods
frozen before transfer).

Maybe Spoon is doing something like this?  As old as Smalltalk is,
someone must be. :)

On 10/18/07, Petr Fischer <petr.fischer at praguesoft.cz> wrote:
> Hi. What do you recommend for communication among running images?
> RemoteMessagingToolkit (RMT)?
> Remote smalltalk (rST)?
> Soap (ehm)?
> other (not via. TCP/IP stack - for multiple images running locally)?
>
> Thanks, p.
>
> On 18.10.2007, at 16:18, Sebastian Sastre wrote:
>
> > Hey this sounds a an interesting path to me. If we think in nature
> > and it's
> > design, that images could be analog to cells of a larger body.
> > Fragmentation
> > keep things simple without compromising scalability. Natural facts
> > concluded
> > that is more efficient not to develop few supercomplex brain cells
> > but to
> > develop zillions of a far simpler brain cells, this is, that are just
> > complex enough, and make them able to setup in an inimaginable
> > super complex
> > network: a brain.
> >
> > Other approach that also makes me conclude this is interesting is
> > that we
> > know that one object that is too smart smells bad. I mean it easily
> > starts
> > to become less flexible so less scalable in complexity, less
> > intuitive (you
> > have to learn more about how to use it), more to memorize, maintain,
> > document, etc. So it is smarter but it could happen that it begins
> > to become
> > a bad deal because of beign too costly. Said so, if we think in those
> > flexible mini images as objects, each one using a core we can scale
> > enourmusly and almost trivially in this whole multicore thing and
> > in a way
> > we know it works.
> >
> > Other interesting point is faul tolerance. If one of those images
> > happen to
> > pass a downtime (because a power faliure on the host where they where
> > running or whatever reason) the system could happen to feel it
> > somehow but
> > not being in a complete faiure because there are other images to
> > handle
> > demand. A small (so efficient), well protected critical system can
> > coordinate measures of contention for the "crisis" an hopefully the
> > system
> > never really makes feel it's own crisis to the users.
> >
> > Again I found this is a tradeof about when to scale horizontally or
> > vertically. For hardware, Intel and friends have scaled vertically
> > (more
> > bits and Hz for instance) for years as much as they where
> > phisically able to
> > do it. Now they reached a kind of barrier and started to scale
> > horizontally
> > (adding cores). Please don't fall in endless discussions, like the
> > ones I
> > saw out there, about comparing apples with bannanas because they
> > are fruits
> > but are not comparable. I mean it's about scaling but they are 2
> > different
> > axis of a multidimensional scaling (complexity, load, performance,
> > etc).
> >
> > I'm thinking here as vertical being to make one squeak smarter to
> > be capable
> > to be trhead safe and horizontal to make one smart network of N
> > squeaks.
> >
> > Sometimes one choice will be a good business and sometimes it will
> > be the
> > other. I feel like the horizontal time has come. If that's true, to
> > invest
> > (time, $, effort) now in vertical scaling could happen to be have a
> > lower
> > cost/benefit rate if compared to the results of the investiment of
> > horizontal scaling.
> >
> > The truth is that this is all speculative and I don't know. But I
> > do trust
> > in nature.
> >
> >       Cheers,
> >
> > Sebastian Sastre
> >
> >> -----Mensaje original-----
> >> De: squeak-dev-bounces at lists.squeakfoundation.org
> >> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En
> >> nombre de Ralph Johnson
> >> Enviado el: Jueves, 18 de Octubre de 2007 08:09
> >> Para: The general-purpose Squeak developers list
> >> Asunto: Re: Multy-core CPUs
> >>
> >> On 10/17/07, Steve Wart <steve.wart at gmail.com> wrote:
> >>> I don't know if mapping Smalltalk processes to native
> >> threads is the
> >>> way to go, given the pain I've seen in the Java and C# space.
> >>
> >> Shared-memory parallelism has always been difficult.  People
> >> claimed it was the language, the environment, or they needed
> >> better training.
> >> They always thought that with one more thing, they could "fix"
> >> shared-memory parallelism and make it usable.  But Java has
> >> done a good job with providiing reasonable language
> >> primitives.  There has been a lot of work on making threads
> >> efficient, and plenty of people have learned to write
> >> mutli-threaded Java.  But it is still way too hard.
> >>
> >> I think that shared-memory parallism, with explicit
> >> synchronization, is a bad idea.  Transactional memory might
> >> be a solution, but it eliminates explicit synchronization.  I
> >> think the most likely solution is to avoid shared memory
> >> altogether, and go with message passing.
> >> Erlang is a perfect example of this.  We could take this
> >> approach in Smalltalk by making minimal images like Spoon,
> >> making images that are designed to be used by other images
> >> (angain, like Spoon), and then implementing our systms as
> >> hundreds or thousands of separate images.
> >> Image startup would have to be very fast.  I think that this
> >> is more likely to be useful than rewriting garbage collectors
> >> to support parallelism.
> >>
> >> -Ralph Johnson
> >>
> >
> >
> >
>
>
>
>
>
>