Differences

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

--- at:tutorial:distribution [2007/05/04 09:04] – elisag
+++ at:tutorial:distribution [2007/06/19 16:09] – tvcutsem
@@ Line 24: / Line 24: @@
 AmbientTalk provides language support to make some objects available to other objects residing in remote actors by means of the ''export:as:'' construct.  The ''export:as:'' construct takes as argument an object that is made remotely accessible and a service type under which the object can be discovered. For example, one exports a printing service as follows:
 <code>
-defstripe Printer;
+deftype Printer;
 def service := object: {
 	def print(aDoc) {
@@ Line 33: / Line 33: @@
 </code>
-When an object its exported by its actor, it becomes discoverable by other actors by means of the service type. Internally, this means that the object is placed in the export table of its actor. As shown in the example, a service type is represented by a [[actors#stripes|stripes]]. This means that services types are not associated with a set of methods, but they denote an abstract publication topic that objects exports. As a stripe, a service type can thus be a subtype of one or more other service types. For example, an object could offer a color printing services by exporting the following stripe:
+When an object its exported by its actor, it becomes discoverable by other actors by means of the service type. Internally, this means that the object is placed in the export table of its actor. As shown in the example, a service type is represented by a type tag. This means that services types are not associated with a set of methods, but they denote an abstract publication topic that objects exports. As a type tag, a service type can thus be a subtype of one or more other service types. For example, an object could offer a color printing services by exporting the following type tag:
 <code>
-defstripe ColorPrinter <: Printer;
+deftype ColorPrinter <: Printer;
 </code>
@@ Line 57: / Line 57: @@
 <note>
-We are using a future to get the return value of the ''getName'' asynchrnonus message invocation. For further details about futures and the ''when:becomes:'' language construct, we refer the reader to the previous chapter on the [[actors|concurrency model of AmbientTalk]].
+We are using a future to get the return value of the ''getName'' asynchronous message invocation. For further details about futures and the ''when:becomes:'' language construct, we refer the reader to the previous chapter on the [[actors|concurrency model of AmbientTalk]].
 </note>
@@ 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 semantics for messages sent to remote objects works similar to the inter-actor message sending semantics:
+When an object discovers a service type, the ''when:becomes:'' 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.
+  - Objects are always passed //by far reference//, except for isolate objects which are passed by copy.
   - Native data types are always passed by copy.
 When a remote far reference receives a messages, it flushes the message to the remote object providing that it is connected. If the remote far reference is disconnected, messages are accumulate in its inbox in order to be transmitted once the reference becomes reconnected at a later point in time once the network connection is restored.
@@ Line 118: / Line 117: @@
 <note>
-As you may have noticed, the ''takeOffline'' language construct is reminiscent to the so-called ''delete'' operation provided by some languages without built-in local garbage collection. It is indeed a design decision providing the minimal set of language constructs for distributed memory management. Rather than defining one specific distributed garbage collector directly in the interpreter, we have opted to enable the experimentation of distributed garbage collection techniques from within AmbientTalk itself. Thanks to AmbientTalk reflective infrastructure, it has been possible to build more sophisticated distributed garbage collection techniques to avoid the extra burden that takeOffline places on developers. More specifically, AmbientTalk integrates leasing techniques with the notion of a remote object reference, and provides the resulting ''leased object references''. The system library shipped with AmbientTalk contains a reflective implementation of leased object references together with a set of language constructs to manipulate them.
+As you may have noticed, the ''takeOffline'' language construct is reminiscent to the so-called //delete// operation provided by some languages without built-in local garbage collection. It is indeed a design decision providing the minimal set of language constructs for distributed memory management. Rather than defining one specific distributed garbage collector directly in the interpreter, we have opted to enable the experimentation of distributed garbage collection techniques from within AmbientTalk itself. Thanks to AmbientTalk reflective infrastructure, it has been possible to build more sophisticated distributed garbage collection techniques to avoid the extra burden that takeOffline places on developers. More specifically, AmbientTalk integrates leasing techniques with the notion of a remote object reference, and provides the resulting //leased object references//. The system library shipped with AmbientTalk contains a reflective implementation of leased object references together with a set of language constructs to manipulate them.
 </note>
@@ Line 135: / Line 134: @@
 <note>
-The complete implementation of the instant messenger application explained along this chapter can be found in the file at/demo/InstantMessenger.at.
+The complete implementation of the instant messenger application explained along this chapter can be found in the file ''at/demo/InstantMessenger.at''.
 </note>