In iStoa, the client (kids with Morphic application) connect to a Magma database through an ADSL connection. When a kids has finished with an exercice, several instances relative to kid achievements are recorded in the remote Magma database. Later the teacher can review (and replay) the kid actions and results.
1. My first constraint is the 128 kbits/s up limit used to upload in the database the instances. Indeed the client is blocked for 1 miniute waiting for the data persistence. A first idea is to compress all the serialised data sent to the Magma server. Is it possible? Other option is to embed the Magma commit in a separate thread. I did some tests, but it randomly leads to crash on the server. Is it something some of you look at?
2. Next the teacher reviews the kids activities through a web application (seaside based) + Squeak web plugin. The Squeak web plugin is used to connect to the Magma database and to replay cinematically the kids activities. From there, at each use of the plugin, a connection to the Magma database is opened, and it is slow, too slow. Any thought about how to optimise that?
Best
Hilaire
On Feb 12, 2008 6:25 AM, Hilaire Fernandes hilaire@ofset.org wrote:
In iStoa, the client (kids with Morphic application) connect to a Magma database through an ADSL connection. When a kids has finished with an exercice, several instances relative to kid achievements are recorded in the remote Magma database. Later the teacher can review (and replay) the kid actions and results.
Wow, what a neat app!
- My first constraint is the 128 kbits/s up limit used to upload in the
database the instances. Indeed the client is blocked for 1 miniute waiting for the data persistence. A first idea is to compress all the serialised data sent to the Magma server. Is it possible?
Yes it should be, and the byteArrays magma sends back and forth should compress well. There's a layer called "Ma client server" just between "Magma client" and "Ma object serialization", like this:
Magma client uses Ma client server uses Ma object serialization
The enhancement could be made in MaClientSocket and MaServerSocket could be changed to "compress at the last second", at the entrace to the network, so it is transparent. That would probably be a nice option that may help. Do you know how to compress/uncompress a ByteArray rapidly?
Other option is to embed the Magma commit in a separate thread. I did some tests, but it randomly leads to crash on the server. Is it something some of you look at?
Look for the a discussion Bert and I had on this list when he was doing his Magma back-end for squeaksource. In a nutshell, if the server detects a change to the object-model occurred during serialization, it will signal an error back to you, so you have to use one of the significant (high-priority) blocking methods, which of course dilutes the background benefit.. :(
- Next the teacher reviews the kids activities through a web
application (seaside based) + Squeak web plugin. The Squeak web plugin is used to connect to the Magma database and to replay cinematically the kids activities. From there, at each use of the plugin, a connection to the Magma database is opened, and it is slow, too slow. Any thought about how to optimise that?
Interesting, are you saying you have a Squeak image running inside a web-browser? Which image? Also, did you have to adjust the plug-in VM to allow Network?
Is the image saved with the connection open? That way it will connect as soon as the image launches. But is it also too slow when this image is started on its own straight in the OS?
magma@lists.squeakfoundation.org