Update to "dapr" official name and minor corrections

This is the initial commit changes to reflect "dapr" official names in the document. This commit also includes minor corrections.

concepts/actor/actor_pattern.md

@@ -1,6 +1,6 @@
-# Actor Pattern with Actions
+# Actor Pattern with dapr
 
-Actions is a new programming model that is based on RPC communication between the framework and the user code, namely HTTP. However, it does support developers to write their code using the Actor Pattern. Specifically, Actions allow a contextual Id to be associated with messages. Actions provides:
+dapr is a new programming model that is based on RPC communication between the framework and the user code, namely HTTP. However, it does support developers to write their code using the Actor Pattern. Specifically, dapr allows a contextual Id to be associated with messages. dapr provides:
 
 1) Routing by a contextual Id.
 2) Ensuring single-threaded access per contextual Id.
@@ -10,20 +10,20 @@ The combination of above behaviors delivers essential characteristics of an Acto
 
 ## Authoring an Actor
 
-In Actions, authoring Actor code is no difference with writing any other service code. An Actor in this case is a web server that listens to any number of messages the actor expects to handle.
+In dapr, authoring Actor code is no difference with writing any other service code. An Actor in this case is a web server that listens to any number of messages the actor expects to handle.
 
-When a request is routed to a handler of the web server, a contextual Id may present in the request header. Actions guarantees that requests with the same contextual Id are dispatched to the web server sequentially. 
+When a request is routed to a handler of the web server, a contextual Id may present in the request header. dapr guarantees that requests with the same contextual Id are dispatched to the web server sequentially. 
 
-Hanlder code can set or retrieve state from the Actions sidecar with the contextual Id attached.
+Handler code can set or retrieve state from the dapr sidecar with the contextual Id attached.
 
 ## Talking to an Actor
 
-Just like invoking any other Actions instances, you can send a request to an Actor by doing a POST to the sidecar. The **to** address of your message will be in the format of:
+Just like invoking any other dapr instances, you can send a request to an Actor by doing a POST to the sidecar. The **to** address of your message will be in the format of:
 ```yaml
-<Actions name>.<Contextual Id>
+<Actor name>.<Contextual Id>
 ```
 
-> Actions uses **virtual actors** pattern. You don't need to explicitly create or destroy Actor instances. 
+> dapr uses **virtual actors** pattern. You don't need to explicitly create or destroy Actor instances. 
 
 For example, the following POST request to **/set-temperature** sends a temperature payload to a **theromstat** with id **123**:
 ```json
@@ -39,27 +39,27 @@ For example, the following POST request to **/set-temperature** sends a temperat
 
 Your code can access the response from the actor through the HTTP response body.
 
-Actions also allows you to make direct calls to actors. The Actions sidecar provides a special **/actor** route that can be used to route requests to actor instance. For example, to invoke the above actor directly, send a POST request to:
+dapr also allows you to make direct calls to actors. The dapr sidecar provides a special **/actor** route that can be used to route requests to actor instance. For example, to invoke the above actor directly, send a POST request to:
 ```bash
 http://localhost:<sidecarport>/actors/theromstat/123
 ```
 
 ## Key Differences From a Full Actor Framework
 
-Actions programming model is not an Actor programming model. Although it provides certain actor characteristics, Actions differ from common Actor programming model in several ways.
+dapr programming model is not an Actor programming model. Although it provides certain actor characteristics, dapr differ from common Actor programming model in several ways.
 
 ### Single Activation
 
-Many Actor frameworks requires single activation of an actor at any time. Actions doesn’t offer such guarantees. There should be a single activation for the most of time. However, multiple activations may exist during failovers, scaling, and network partitions. Actions will converge back to single activation when such conditions are resolved. 
+Many Actor frameworks requires single activation of an actor at any time. dapr doesn’t offer such guarantees. There should be a single activation for the most of time. However, multiple activations may exist during failovers, scaling, and network partitions. dapr will converge back to single activation when such conditions are resolved. 
 
-Actions offers exact-once delivery within a configurable window. Actions delivers requests for the same actor id to the same service instance, while serializing client requests as well as state access of an instance. The combination of these features offers a high-fidelity simulation of the single activation behavior. However, there could be corner cases that cause problems when multiple activations do occur. 
+dapr offers exact-once delivery within a configurable window. dapr delivers requests for the same actor id to the same service instance, while serializing client requests as well as state access of an instance. The combination of these features offers a high-fidelity simulation of the single activation behavior. However, there could be corner cases that cause problems when multiple activations do occur. 
 
 ### State Transaction Scope
 
-Some Actor frameworks allow wrapping multiple state operations into an atomic transaction. In Actions, each state operation is a separate transaction. Because Actions doesn't dictate how user code is written, a user may trigger multiple state transactions in her code. If the code crashes between transactions, the state is left at the last committed transaction.
+Some Actor frameworks allow wrapping multiple state operations into an atomic transaction. In dapr, each state operation is a separate transaction. Because dapr doesn't dictate how user code is written, a user may trigger multiple state transactions in the code. If the code crashes between transactions, the state is left at the last committed transaction.
 
 
 ## More Information
-To learn more about Actions Actor Pattern support, consult the following topics:
+To learn more about dapr Actor Pattern support, consult the following topics:
 
 * [Enabling the Actor Pattern](../../topics/enable_actor_pattern.md)

concepts/actor/actors_integration.md

@@ -1,29 +1,30 @@
 # Integration with Actor Frameworks
-This article introduces how Actions integrate with existing Actor Frameworks such as [Orleans](https://github.com/dotnet/orleans), [Akka](https://akka.io/), and [Service Fabric Reliable Actors](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction). With Actions integration, these Actor frameworks will allow developers to write Actor code in any programming languages, and to plug their Actors into Actions eventing pipeline that enables reliable messaging, pub-sub, binding to event sources and many other features.
+This article introduces how dapr integrate with existing Actor Frameworks such as [Orleans](https://github.com/dotnet/orleans), [Akka](https://akka.io/), and [Service Fabric Reliable Actors](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction). With dapr integration, these Actor frameworks will allow developers to write Actor code in any programming languages, and to plug their Actors into dapr eventing pipeline that enables reliable messaging, pub-sub, binding to event sources and many other features.
 
 ## Client-side integration
-On the cliend side, Actions acts as a shim in front of an Actor proxy. This allows Actions to bring reliable messaging, binding and other features to the connected Actor framework.
+On the client side, dapr acts as a shim in front of an Actor proxy. This allows dapr to bring reliable messaging, binding and other features to the connected Actor framework.
 ![Actors client](../imgs/actors_client.png)
 
 ## Server-side integration
-On the server side, Actions leverages Actor framework capabilities such as state management and single activation guarantee to offer complete Actor framework capabilities. Actions defines an **Actor API**, which the integrated Actor frameworks are supposed to implement/support. 
+On the server side, dapr leverages Actor framework capabilities such as state management and single activation guarantee to offer complete Actor framework capabilities.
+dapr defines an **Actor API**, which the integrated Actor frameworks are supposed to implement/support. 
 
-> Actions comes with a built-in Actor framework implemenation through the same Actor API.
+> dapr comes with a built-in Actor framework implemenation through the same Actor API.
 
 The following diagram illustrates two possible execution paths. ![Actors server](../imgs/actors_server.png)
 
 ### Client calling an Actor (green path)
 
 1. A client makes a call to an Actor instance.
-2. Actions calls an Actor proxy to forward the request.
-3. As the Actor runtime activates/invokes an Actor, it calls Actions through the Actor API to invoke the user method.
-4. Actions forwards the request to user code through Actions API.
+2. dapr calls an Actor proxy to forward the request.
+3. As the Actor runtime activates/invokes an Actor, it calls dapr through the Actor API to invoke the user method.
+4. dapr forwards the request to user code through dapr API.
 5. As the response is returned, it was sent back to client as a response to the original request. 
 
 ### A message triggering an Actor (yellow path)
 
-1. A message is routed to the Actions instance that is hosting the destination Actor.
-2. Actions dispatches the message to the Actor runtime when possible.
+1. A message is routed to the dapr instance that is hosting the destination Actor.
+2. dapr dispatches the message to the Actor runtime when possible.
 3. The rest of the steps are the same as the green path.
 
 ## Actor API
@@ -36,5 +37,5 @@ At a high level, the Actor API shall contain the following methods:
 * Locate & send message to an Actor 
 
 ## Custom Programming Experience
-Custom programming experiences can be built on top of Actions through a custom library. The Custom library adapts Actions API to a custom API shape that the user code consumes, as shown in the following diagram:
+Custom programming experiences can be built on top of dapr through a custom library. The Custom library adapts dapr API to a custom API shape that the user code consumes, as shown in the following diagram:
 ![custom_experience](../imgs/programming_experience.png)

concepts/actor/enable_actor_pattern.md

@@ -1,17 +1,16 @@
 # Enabling the Actor Pattern
-The Actor Pattern has been broadly used in modeling complex distributed systems in which a large number of individual agents work together. For example, in many IoT solutions, actors are often used as digital presences of physical devices. Actions supports the Actor Pattern by offering key characteristics of an actor. This document introduces architecturally how Actions enables the Actor Pattern. To learn about how to use the Actor Pattern with Actions, please read [this document](../concepts/actor/actor_pattern.md).
+The Actor Pattern has been broadly used in modeling complex distributed systems in which a large number of individual agents work together. For example, in many IoT solutions, actors are often used as digital presences of physical devices. dapr supports the Actor Pattern by offering key characteristics of an actor. This document introduces architecturally how dapr enables the Actor Pattern. To learn about how to use the Actor Pattern with dapr, please read [this document](../concepts/actor/actor_pattern.md).
 
 ## Overview
-Actions uses an off-path **partition table** to assign actor ids to service instances so that requests to the same actor id is always routed to the same instance. The partition table is dynamically adjusted when re-partitioning or failover happens. Changes to the table are broadcasted to Actions sidecars to update their own settings to match with the global table. 
+dapr uses an off-path **partition table** to assign actor ids to service instances so that requests to the same actor id is always routed to the same instance. The partition table is dynamically adjusted when re-partitioning or failover happens. Changes to the table are broadcasted to dapr sidecars to update their own settings to match with the global table. 
 
 A client can talk to an actor through either reliable messaging or direct invocation, as illustrated by the following diagram:
 ![actor pattern](../imgs/actor_pattern.png)
 
 ### Calling an actor through messaging
-1. When a process pair of user code and Actions sidecar comes up, the sidecar registers the pair (such as a Pod on Kubernetes) with a **partition table** hosted on the Actions control plane.
-2. The partition table updates itself to reflect the topology change. 
-Then, it broadcasts a change notification to all Actions sidecars.
-3. The Actions sidecar updates its own settings to poll messages from corresponding partitions of a reliable queue.
+1. When a process pair of user code and dapr sidecar comes up, the sidecar registers the pair (such as a Pod on Kubernetes) with a **partition table** hosted on the dapr control plane.
+2. The partition table updates itself to reflect the topology change.Then, it broadcasts a change notification to all dapr sidecars.
+3. The dapr sidecar updates its own settings to poll messages from corresponding partitions of a reliable queue.
 4. The client code sends requests to the reliable queue, which puts the requests in corresponding partitions based on the associated contextual ids. Then, the messages are picked up and consumed during the next poll.
 
 ### Calling an actor through direct invocation
@@ -20,29 +19,29 @@ Then, it broadcasts a change notification to all Actions sidecars.
 
 ## Messaging
 
-When enabled, each Actions sidecar has a designated reliable message queue. This allows the sidecar to sequentialize requests to a specific actor id. Actions supports at-least-once delivery and exact-once delivery within a configurable time window. Please see [reliable messaging](TBD) for more details.
+When enabled, each dapr sidecar has a designated reliable message queue. This allows the sidecar to sequentialize requests to a specific actor id. dapr supports at-least-once delivery and exact-once delivery within a configurable time window. Please see [reliable messaging](TBD) for more details.
 
 Reliable messing is not used for direct invocations. In such a case, user code is expected to handle response errors and retry the request as needed.
 
 ## State Management
 
-All state access are encapsulated in a **state provider**. Actions expects a state provider to offer state partitioning for scale and replication for high availability and reliability. 
+All state access are encapsulated in a **state provider**. dapr expects a state provider to offer state partitioning for scale and replication for high availability and reliability. 
 
-Because all requests to an actor instance are routed to the same Actions service instance, the user code can use local variables as local caches of its state.
+Because all requests to an actor instance are routed to the same dapr service instance, the user code can use local variables as local caches of its state.
 
-When Actions routes an actor instance to a new Actions service instance, it invokes the **/state** endpoint so that the actor instance can restore state from the state store.
+When dapr routes an actor instance to a new dapr service instance, it invokes the **/state** endpoint so that the actor instance can restore state from the state store.
 
 ## Partition Table
 
-Actions uses different strategies to mange and use the partition table for different scenarios. Although partition table doesn’t sit on active data path, Actions tries to employ any possible optimizations to minimize the overheads of table management and lookups.
+dapr uses different strategies to manage and use the partition table for different scenarios. Although partition table doesn’t sit on active data path, dapr tries to employ any possible optimizations to minimize the overheads of table management and lookups.
 
 ### Skipping the table
 
-If an Actions service is stateless, and if only direct invocation is needed, the partition table is skipped. In this case, requests to actor instances are distributed by the service load balancer.
+If an dapr service is stateless, and if only direct invocation is needed, the partition table is skipped. In this case, requests to actor instances are distributed by the service load balancer.
 
-If an Actions service is stateless, and is known to have light traffic so that messaging system partition is not needed, the table can also be skipped even when reliable messaging is used, because all Actions instances will simply compete for the latest messages from the same partition.
+If an dapr service is stateless, and is known to have light traffic so that messaging system partition is not needed, the table can also be skipped even when reliable messaging is used, because all dapr instances will simply compete for the latest messages from the same partition.
 
-If Actions services have stable identifiers (i.e. doesn’t change when restarted or relocated), and both the possible range of actor Ids and all Actions service ids are known, a predefined algorithm can be used to decide actor partitions instead of looking up the partition table. However, in such a case, dynamic partitioning is not allowed.
+If dapr services have stable identifiers (i.e. doesn’t change when restarted or relocated), and both the possible range of actor Ids and all dapr service ids are known, a predefined algorithm can be used to decide actor partitions instead of looking up the partition table. However, in such a case, dynamic partitioning is not allowed.
 
 ### Range-only table
 
@@ -64,9 +63,9 @@ In the above discussion, it's been assumed that service instances have stable id
 
 ## Sequential Access
 
-When configured to run as actors, Actions sidecar dispatches messages to user code. The user code is free to use whatever threading model of choice to handle these messages. When the user code tries to preserve state, the state write requests are again dispatched to the underlying state store sequentially.
+When configured to run as actors, dapr sidecar dispatches messages to user code. The user code is free to use whatever threading model of choice to handle these messages. When the user code tries to preserve state, the state write requests are again dispatched to the underlying state store sequentially.
 
-Actions allows read-only requests (signified by the GET verb) to be routed to any service instances. This allows the single-writer-multiple-reader pattern, in which readers get eventual consistent (but almost always up-to-date - the delta is the single in-flight transaction) reads on actor states.
+dapr allows read-only requests (signified by the GET verb) to be routed to any service instances. This allows the single-writer-multiple-reader pattern, in which readers get eventual consistent (but almost always up-to-date - the delta is the single in-flight transaction) reads on actor states.
 
 Such sequential access pattern is broken when multiple activations occur. For example, due to network partition, two service instances get different partition table data and try to poll data from the same partition. One message for an actor goes to intance A and the subsquent message for the same actor goes to instance B. This may lead to consistency issues. 
 
@@ -74,4 +73,4 @@ One way to partially mitigate this is to add a auto-increment version tag on sta
 
 ## Summary
 
-Actions can be used as building blocks to build a complete Actor framework but itself isn’t one. As a developer, you should be aware that when you use Actions by itself, you can configure it to offer some characteristics of an Actor, but you should not assume it gives a complete feature set as a complete Actor framework.
+dapr can be used as building blocks to build a complete Actor framework but itself isn’t one. As a developer, you should be aware that when you use dapr by itself, you can configure it to offer some characteristics of an Actor, but you should not assume it gives a complete feature set as a complete Actor framework.