Nothing complex about two images exchanging messages, its not even complex to transmit objects via fuel, you even transmit a debugger or any part of the live environment or even make an "internet" of images that join objects together. Sky is the limit. Pharo already provides you will all the tools/libraries to do this.
Yes. That���s why I asked for better practices.
A streamsocket (not to be confused with regular sockets) will delay the messages (a collection of bytes) until they arrive to the receiver or until they have reached the timeout period. Offline mode is pretty much obligatory even for plain old internet web apps because of drops in connection or the plain fact a connection can become slow.
Offline mode is to me of first importance.
Let���s say I have a sets of Pharo app (nodes).
Each one are independent running on different devices/computers.
I want to exchange information between them according to some kind of contracts and also on connection availability.
What I find different from usual message exchanges between two images is that I want to have full control on it. Plus I consider images offline by default (meaning two images have different versions of the same info). So conflict is the norm.
Also, I don���t want to send message remotely (with behavior), I just want to send/share an information and sync them (when possible).
Connection between 2 images can be through a network but eventually through a serial connection (usb cable, Bluetooth,...).
So what I try to do as a proto is having connection controlled by my apps (I put the app offline (not by switching off wifi but by switching logically). I can see nodes availability and activate connexion manually then see if conflict resolution is ok, + I log every connecitions changes and exchanges). This is my plans for now but it may change ! ^^
I used streamsockets in my Pharo to Python bridge (Atlas) because the execution was not necessary synchronous , I was sending Python command to a 3d application from Pharo and I had to make sure that the bridge was working even in the case of a command that could take hours to execute like a rendering process.
I���ll look at stream sockets and mq stuffs.
Cheers,
C��drick
One cool trick I did was to send the Python errors back to Pharo and trigger them as Pharo's regular MessageNotUnderstood , this is a nice way to make sure that you can fix a wrong message after it has been executing without going to the image that is executing it.
The limitation with sockets which what every frameworks uses because AFAIK they are the only means to communicate remotely is that they are not top performance so that mean that you can send long loops but executing communication inside long loops will either slow you down considerably or simply timeout your socket. Sockets can timeout from both ends if they feel that for some reason they lost communication with the other side and reached their timeout period. Timeout period is customization.
This is a problem I did not tackle with my implementation because I dont think there can be an actual practical solution better than avoiding this scenario.
Only shared memory seems to overcome this but it can be used only locally and not remotely (aka on same computer) .
I had a look and this is not (natively) possible.
The idea of the off-line mode would be to delay messages that are sent to the peer until a connection is established.
I think I have to try to do it by myself (like having a list of information exchange that wait until a connexion is established).
What I try to do is not as complex as two general image exchanging messages on objects (like on TelePharo).
I just want a repository of information (mainly a collection of static information/data versions) on both peers to be synchronized when a connection is established.