This is an automated email from the ASF dual-hosted git repository.
sjwiesman pushed a commit to branch release-3.0
in repository https://gitbox.apache.org/repos/asf/flink-statefun.git
The following commit(s) were added to refs/heads/release-3.0 by this push:
new 0f829e1 [hotfix] various tpyos in the docs
0f829e1 is described below
commit 0f829e1129acbc4d92f269dc8b4f6ed832d510a6
Author: Konstantin Knauf <[email protected]>
AuthorDate: Thu Apr 1 14:51:05 2021 +0200
[hotfix] various tpyos in the docs
This closes #219
---
.../content/docs/concepts/application-building-blocks.md | 2 +-
docs/content/docs/concepts/distributed_architecture.md | 4 ++--
docs/content/docs/concepts/logical.md | 2 +-
docs/content/docs/deployment/configurations.md | 2 +-
docs/content/docs/deployment/embedded.md | 5 +----
docs/content/docs/deployment/module.md | 2 +-
docs/content/docs/io-module/overview.md | 2 +-
docs/content/docs/sdk/java.md | 10 +++++-----
docs/content/docs/sdk/python.md | 16 ++++++++--------
9 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/docs/content/docs/concepts/application-building-blocks.md
b/docs/content/docs/concepts/application-building-blocks.md
index 4bf236c..d82ca23 100644
--- a/docs/content/docs/concepts/application-building-blocks.md
+++ b/docs/content/docs/concepts/application-building-blocks.md
@@ -35,7 +35,7 @@ Stateful Function applications sit squarely in the event
driven space, so the na
{{< img width="80%" src="/fig/concepts/statefun-app-ingress.svg" >}}
-In stateful functions, the component that ingests records into the system is
called an event ingress.
+In Stateful Functions, the component that ingests records into the system is
called an event ingress.
This can be anything from a Kafka topic, to a messsage queue, to an http
request - anything that can get data into the system and trigger the intitial
functions to begin computation.
## Stateful Functions
diff --git a/docs/content/docs/concepts/distributed_architecture.md
b/docs/content/docs/concepts/distributed_architecture.md
index dd35cd4..3c64181 100644
--- a/docs/content/docs/concepts/distributed_architecture.md
+++ b/docs/content/docs/concepts/distributed_architecture.md
@@ -43,7 +43,7 @@ The Flink cluster consists typically of one master and
multiple workers (TaskMan
{{< img width="80%" src="/fig/concepts/arch_components.svg" >}}
-In addition to the Apache Flink processes, a full deployment requires
[ZooKeeper](https://zookeeper.apache.org/) (for [master
failover](https://ci.apache.org/projects/flink/flink-docs-stable/ops/jobmanager_high_availability.html))
and bulk storage (S3, HDFS, NAS, GCS, Azure Blob Store, etc.) to store Flink's
[checkpoints](https://ci.apache.org/projects/flink/flink-docs-master/concepts/stateful-stream-processing.html#checkpointing).
In turn, the deployment requires no database, and Flink [...]
+In addition to the Apache Flink processes, a full deployment requires
[ZooKeeper](https://zookeeper.apache.org/) or Kubernetes (for [master
failover](https://ci.apache.org/projects/flink/flink-docs-stable/deployment/ha/))
and bulk storage (S3, HDFS, NAS, GCS, Azure Blob Store, etc.) to store Flink's
[checkpoints](https://ci.apache.org/projects/flink/flink-docs-master/concepts/stateful-stream-processing.html#checkpointing).
In turn, the deployment requires no database, and Flink processes [...]
## Logical Co-location, Physical Separation
@@ -66,7 +66,7 @@ Function invocations happen through an HTTP / gRPC protocol
and go through a ser
{{< img width="80%" src="/fig/concepts/arch_funs_remote.svg" >}}
-Refer to the documentation on the [Python SDK]({{< ref "docs/sdk/python" >}})
for details.
+Refer to the documentation on the [Python SDK]({{< ref "docs/sdk/python" >}})
or [Java SDK]({{< ref "docs/sdk/java" >}}) for details.
#### Co-located Functions
diff --git a/docs/content/docs/concepts/logical.md
b/docs/content/docs/concepts/logical.md
index c3e9795..20f08f4 100644
--- a/docs/content/docs/concepts/logical.md
+++ b/docs/content/docs/concepts/logical.md
@@ -48,7 +48,7 @@ When a function is being invoked, all actions - including
reads and writes of pe
For example, imagine there was a Stateful Functions application to track the
inventory of a warehouse.
One possible implementation could include an ``Inventory`` function that
tracks the number units in stock for a particular item; this would be the
function type.
-There would then be one logical instance of this type for each SKU the
warehouse manages.
+There would then be one logical instance of this type for each stock-keeping
unit (SKU) the warehouse manages.
If it were clothing, there might be an instance for shirts and another for
pants; "shirt" and "pant" would be two IDs.
Each instance may be interacted with and messaged independently.
The application is free to create as many instances as there are types of
items in inventory.
diff --git a/docs/content/docs/deployment/configurations.md
b/docs/content/docs/deployment/configurations.md
index 9491b2c..271e752 100644
--- a/docs/content/docs/deployment/configurations.md
+++ b/docs/content/docs/deployment/configurations.md
@@ -67,7 +67,7 @@ These may be set through your job's ``flink-conf.yaml``.
<td><h5>statefun.feedback.memory.size</h5></td>
<td style="word-wrap: break-word;">32 MB</td>
<td>Memory</td>
- <td>TThe number of bytes to use for in memory buffering of the
feedback channel, before spilling to disk.</td>
+ <td>The number of bytes to use for in memory buffering of the
feedback channel, before spilling to disk.</td>
</tr>
</tbody>
</table>
\ No newline at end of file
diff --git a/docs/content/docs/deployment/embedded.md
b/docs/content/docs/deployment/embedded.md
index f9f4e7f..0c0c7ff 100644
--- a/docs/content/docs/deployment/embedded.md
+++ b/docs/content/docs/deployment/embedded.md
@@ -67,10 +67,7 @@ org.apache.flink.statefun.docs.EmbeddedModule
Embedded modules should be packaged as a fat-jar, containing all required
dependencies and added to the StateFun runtime image.
```dockerfile
-FROM flink-statefun:{{< version >}}
-
-RUN mkdir -p /opt/statefun/modules/config
-COPY module.yaml /opt/statefun/modules/config/module.yaml
+FROM ververica/flink-statefun:{{< version >}}
RUN mkdir -p /opt/statefun/modules/my-embedded
COPY embedded.jar /opt/statefun/modules/my-embedded/embedded.jar
diff --git a/docs/content/docs/deployment/module.md
b/docs/content/docs/deployment/module.md
index 4f8d534..6f82517 100644
--- a/docs/content/docs/deployment/module.md
+++ b/docs/content/docs/deployment/module.md
@@ -116,7 +116,7 @@ endpoint:
#### Typename
The meta `typename` is the logical type name used to match a function
invocation with a physical endpoint.
-Typenames are compsed of a namespace (required) and name (optional).
+Typenames are composed of a namespace (required) and name (optional).
Endpoints containing a namespace but no name will match all function types in
that namespace.
{{< hint info >}}
diff --git a/docs/content/docs/io-module/overview.md
b/docs/content/docs/io-module/overview.md
index b647d88..b21e826 100644
--- a/docs/content/docs/io-module/overview.md
+++ b/docs/content/docs/io-module/overview.md
@@ -78,7 +78,7 @@ Each egress is defined using two components, an
``EgressIdentifier`` and an ``Eg
An egress identifier uniquely identifies an egress based on a namespace, name,
and producing type.
An egress spec defines the details of how to connect to the external system,
the details are specific to each individual I/O module.
-Each identifier-spec pair are bound to the system inside a stateful function
module.
+Each identifier-spec pair is bound to the system inside a Stateful Functions
module.
```yaml
version: "3.0"
diff --git a/docs/content/docs/sdk/java.md b/docs/content/docs/sdk/java.md
index 109ea9d..4a1ca67 100644
--- a/docs/content/docs/sdk/java.md
+++ b/docs/content/docs/sdk/java.md
@@ -77,7 +77,7 @@ public class GreeterFn implements StatefulFunction {
This code declares a greeter function that will be
[registered](#serving-functions) under the logical type name
`com.example.fns/greeter`. Type names must take the form `<namesapce>/<name>`.
It contains a single `ValueSpec`, which is implicitly scoped to the current
address and stores an integer.
-Every time a message is sent a greeter instance, it is interpreted as a
`string` represting the users name.
+Every time a message is sent to a greeter instance, it is interpreted as a
`string` representing the users name.
Both messages and state are strongly typed - either one of the default
[built-in types]({{< ref "docs/sdk/appendix#types" >}}) - or a [custom
type](#types).
The function finally builds a custom greeting for the user.
@@ -87,7 +87,7 @@ and the greeting is sent to the users' inbox (another
function type).
## Types
Stateful Functions strongly types all messages and state values.
-Because they run in a distributed manner and state values are persisted to
stable storage, Stateful Functions aims to provide efficient and easy to user
serializers.
+Because they run in a distributed manner and state values are persisted to
stable storage, Stateful Functions aims to provide efficient and easy to use
serializers.
Out of the box, all SDKs offer a set of highly optimized serializers for
common primitive types; boolean, numerics, and strings.
Additionally, users are encouraged to plug-in custom types to model more
complex data structures.
@@ -96,7 +96,7 @@ In the [example above](#defining-a-stateful-function), the
greeter function cons
Often, functions need to consume more complex types containing several fields.
By defining a custom type, this object can be passed transparently between
functions and stored in state.
-And because the type is tied to a logical typename, instead of the physical
Python class, it can be passed to functions written in other langauge SDKs.
+And because the type is tied to a logical typename, instead of the physical
Python class, it can be passed to functions written in other language SDKs.
```java
import com.fasterxml.jackson.annotation.JsonCreator;
@@ -146,11 +146,11 @@ public class User {
## State
Stateful Functions treats state as a first class citizen and so all functions
can easily define state that is automatically made fault tolerant by the
runtime.
-State declaration is as simple as defining one or more `ValueSpec`'s
describing your state values.
+State declaration is as simple as defining one or more `ValueSpec`s describing
your state values.
Value specifications are defined with a unique (to the function) name and
[type](#types).
{{< hint info >}}
-All value specificiations must be earerly registered in the
`StatefulFuctionSpec` when composing
+All value specifications must be eagerly registered in the
`StatefulFuctionSpec` when composing
the applications [RequestReplyHandler](#serving-functions).
{{< /hint >}}
diff --git a/docs/content/docs/sdk/python.md b/docs/content/docs/sdk/python.md
index 6304b5a..c9cde7d 100644
--- a/docs/content/docs/sdk/python.md
+++ b/docs/content/docs/sdk/python.md
@@ -40,9 +40,9 @@ apache-flink-statefun=={{< version >}}
## Defining A Stateful Function
-A stateful function is any function that takes a `context` and message
parameter.
+A stateful function is any function that takes a `context` and `message`
parameter.
In the following example, a `StatefulFunction` maintains a count for every user
-of an application, emiting a customized greeting.
+of an application, emitting a customized greeting.
```python
from statefun import *
@@ -69,17 +69,17 @@ async def greet(ctx: Context, message: Message):
This code declares a greeter function that will be
[registered](#serving-functions) under the logical type name
`com.example.fns/greeter`. Type names must take the form `<namesapce>/<name>`.
It contains a single `ValueSpec`, which is implicitly scoped to the current
address and stores an integer.
-Every time a message is sent a greeter instance, it is interpreted as a
`string` represting the users name.
+Every time a message is sent a greeter instance, it is interpreted as a
`string` representing the users name.
Both messages and state are strongly typed - either one of the default
[built-in types]({{< ref "docs/sdk/appendix#types" >}}) - or a [custom
type](#types).
The function finally builds a custom greeting for the user.
The number of times that particular user has been seen so far is queried from
the state store and updated
-and the greeting is sent to the users' inbox (another function type).
+and the greeting is sent to the user's inbox (another function type).
## Types
Stateful Functions strongly types all messages and state values.
-Because they run in a distributed manner and state values are persisted to
stable storage, Stateful Functions aims to provide efficient and easy to user
serializers.
+Because they run in a distributed manner and state values are persisted to
stable storage, Stateful Functions aims to provide efficient and easy to use
serializers.
Out of the box, all SDKs offer a set of highly optimized serializers for
common primitive types; boolean, numerics, and strings.
Additionally, users are encouraged to plug-in custom types to model more
complex data structures.
@@ -88,7 +88,7 @@ In the [example above](#defining-a-stateful-function), the
greeter function cons
Often, functions need to consume more complex types containing several fields.
By defining a custom type, this object can be passed transparently between
functions and stored in state.
-And because the type is tied to a logical typename, instead of the physical
Python class, it can be passed to functions written in other langauge SDKs.
+And because the type is tied to a logical typename, instead of the physical
Python class, it can be passed to functions written in other language SDKs.
```python
from statefun import *
@@ -110,11 +110,11 @@ UserType = simple_type(
## State
Stateful Functions treats state as a first class citizen and so all functions
can easily define state that is automatically made fault tolerant by the
runtime.
-State declaration is as simple as defining one or more `ValueSpec`'s
describing your state values.
+State declaration is as simple as defining one or more `ValueSpec`s describing
your state values.
Value specifications are defined with a unique (to the function) name and
[type](#types).
{{< hint info >}}
-All value specificiations must be earerly registered in the `StatefulFuctions`
decorator when declaring the function.
+All value specifications must be eagerly registered in the `StatefulFuctions`
decorator when declaring the function.
{{< /hint >}}
```python
