Differences

This shows you the differences between two versions of the page.

--- at:tutorial:distribution [2007/05/04 08:34] – * elisag
+++ at:tutorial:distribution [2007/05/04 08:35] – * elisag
@@ Line 69: / Line 69: @@
 Let us consider again the example instant messenger application described in previous section to further explain the semantics of AmbientTalk's remote object references and how they deal with transient disconnections.
-When an object discovers a service type, the ''when'' observers are triggered receiving as parameter a remote far reference to the remote object discovered. As explained in previous sections, far references operates asynchronously. When a client object sends a message via a remote reference, the message is buffered in the remote far reference and the client does not even wait for the message to be delivered. This is crucial in distributed computing in order to prevent race conditions. The parameter passing in the context of distribution works similar to the inter-actor message sending semantics:
+When an object discovers a service type, the ''when'' observers are triggered receiving as parameter a remote far reference to the remote object discovered. As explained in previous sections, far references operates asynchronously. When a client object sends a message via a remote reference, the message is buffered in the remote far reference and the client does not even wait for the message to be delivered. This is crucial in distributed computing in order to prevent race conditions. The parameter passing semantics for messages sent to remote objects works similar to the inter-actor message sending semantics:
   - Objects are always passed by far reference, except for isolate objects which are passed by copy.
@@ Line 107: / Line 107: @@
 </note>
-On the client side, taking offline an object results in a permanent disconnection of the remote references pointing to it. In other words, despite having network connection, unexporting an object renders remote far references permanently disconnected. This implies that client have to deal explicitly with unexported objects. To this end, ''when:takenOffline'' was implemented in order for developers to be able to install observers on an far reference which are notified when the object pointed to is taken offline. The construct takes as parameter a far reference and a block of code that is executed when the taken offline event is notified. As an example, the instant messenger application can clean certain resources when a buddy shuts down its instant messenger application as follows:
+On the client side, taking offline an object results in a permanent disconnection of the remote references pointing to it. In other words, despite having network connection, unexporting an object renders remote far references permanently disconnected. This implies that client have to deal explicitly with unexported objects. To this end, ''when:takenOffline'' has been implemented in order for developers to be able to install observers on an far reference which are notified when the object pointed to is taken offline. The construct takes as parameter a far reference and a block of code that is executed when the taken offline event is notified. As an example, the instant messenger application can clean certain resources when a buddy shuts down its instant messenger application as follows:
 <code>