Passing objects between clients

[Nick Brown]

Thanks Chris. I'll look into those. (Maybe the Ma Client Server could do 
with being mentioned more prominently among the Magma pages on the swiki 
- I missed it completely.)

Cheers,
Nick

Chris Muller wrote:
> Hi Nick, have a look at MagmaTestCase>>#testSequenceNumberGenerator,
> in the MagmaTester package.  This demonstrates how to use MagmaCounter
> to synchronize a counter object between all clients.
>
> By using a couple of Counters that index into a MagmaArray, you may
> implement a "MagmaQueue", that would be synchronized between all
> clients.
>
> If you don't want the clients to have to poll the database for a piece
> of work, please also note the "Ma Client Server" framework is easy to
> use independently of Magma, and is pretty robust.  Whoever is pushing
> the work onto the queue could simply send the work directly to another
> MagmaClient or send just a reference-id to the work-request in the
> database (have a look at #requiredProgress for making the latter
> work).
>
> The MagmaTester uses "Ma Client Server", on its own, without Magma, to
> run its test-suite.  By having a "conductor" image which simply sends
> out remotePerform:withArguments: to three other images (two clients
> and a server) to tell them to do various things for the test.  See the
> swiki for more information on "Ma Client Server".
>
>  - Chris
>
>
>   
>> I'm interested in using it to allow pieces of work (which I'll call 'jobs')
>> to be handed out to one or more Squeak images ('workers').
>>
>> On startup, each worker opens a connection to the Magma server, checks to
>> see whether there are any jobs waiting to be done. If there are, the worker
>> will take the first job off the queue, run it, and ultimately commit the
>> result of the job back into Magma.
>>
>> Other Magma clients are periodically going to push new jobs onto the end of
>> the queue.
>>
>> My first attempt just used an OrderedCollection to represent the queue, with
>> one Magma client adding Arrays of numbers to it with #add: to simulate jobs
>> being added; and another client removing them with #removeFirst; to simulate
>> jobs being accepted by a worker.
>>
>> This approach is prone to conflicts, presumably because each #add: or
>> #removeFirst: is attempting to rewrite the entire internal state of the
>> OrderedCollection.
>>
>> So my question is, is there a better way of doing this? Use Magma to pass
>> semaphores between clients? Or just live with the conflicts?
>>
>> Thanks for any insight.
>>
>> -Nick
>>
>> _______________________________________________
>> Magma mailing list
>> Magma at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>
>>