Göran wrote:

> Well, you can combine a "remote message" framework with it to get that
> kind of distributed messaging too. 

It seems maybe some are not aware that Magma *includes* its own "remote
message" framework.  It's called "Ma client server" and is available
independently of Magma on SqueakMap right now.

Magma uses this relatively simple framework for all of its network
communications.  I also use it in MagmaTester, also available now on SqueakMap,
to remotePerform: #selectorSymbol and remoteEvaluate: '<some Smalltalk code>'
from my 'test director' image in the context of the "test-player" servers. 
It's a nice way to test network programs.

Now, there is one important difference between this and what GemStone/S
provides, which is dynamically changing the "locus of execution" AND
maintaining *concurrency detection*.  For example, with GemStone/S, when you
"remotePerform" it is *in the context of your GemStone session*.  In Magma, you
choose whether you want a server that hosts a Magma repository that has *truely
local* Magma sessions (e.g., in the same Squeak image) for each client in its
image.  Avi Bryant wanted this for web-server programs and still use Magma's
very good concurrency detection mechanism.  Support for this was implemented as
of 1.0gamma3 (the current release).

BUT, for programs OTHER THAN web programs, I dare suggest that.. the two-tier
model, where you have clients and APPLICATION servers all sharing an object
model via a single Magma DATABASE server, is the simplest and best model in
that it lets the Magma server be concerned with nothing but the database
operations, thus maximizing the computing power available all over the network.
 Client power (e.g., PC's) offers the highest power/price ratio.  Magma can
handle lots of clients (especially in the upcoming 1.0gamma4) by virtue of the
server operations being generally very short and most of the work is done on
the clients.

And you can still have other "application" servers running concurrently on
other machines to do work by using RMI.  Perhaps they have a bunch of
pre-cached objects that allow it to go faster, or maybe its just a big machine,
and it would have its own Magma client sessions connected to the SAME
repository as all the other clients so as to be operating on the same shared
object model.

> 3. Start another Magma client on another machine. Let it connect to the
> Magma server. Let it communicate through the model - for example, create
> an OrderedCollection in Magma. Let the client add a Job instance and
> commit that. The server Squeak process can then discover these, process
> the jobs and remove them from the queue. So the client is using Magma to
> communicate with the server.

In the upcoming 1.0gamma4 release, Magma supports a new preference for
changed-notifications a la the simple variation of the Listener pattern.  That
is, whenever you cross a transaction boundary, if the preference is set true,
it will send #magmaChanged to all objects that were changed by other other
sessions.

This is one way that the "server Squeak process" mentioned above would be able
to "discover" the changes.

Regards,
  Chris


__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com