This is an automated email from the ASF dual-hosted git repository.
xuanwo pushed a commit to branch blog-how-opendal-read-data
in repository https://gitbox.apache.org/repos/asf/incubator-opendal.git
The following commit(s) were added to refs/heads/blog-how-opendal-read-data by
this push:
new 18cd596c4 Address comments
18cd596c4 is described below
commit 18cd596c4f2030b3cf71ff24f67a19cd93861f0d
Author: Xuanwo <[email protected]>
AuthorDate: Tue Aug 15 23:08:47 2023 +0800
Address comments
Signed-off-by: Xuanwo <[email protected]>
---
website/blog/2023-08-15-how-opendal-read-data/index.md | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/website/blog/2023-08-15-how-opendal-read-data/index.md
b/website/blog/2023-08-15-how-opendal-read-data/index.md
index ef8642d9c..33d3ed1ec 100644
--- a/website/blog/2023-08-15-how-opendal-read-data/index.md
+++ b/website/blog/2023-08-15-how-opendal-read-data/index.md
@@ -54,7 +54,7 @@ The internal logic of the Operator would look like this:
Its main job is to encapsulate the interface for the user:
-- Completing the construction of `OpRead`
+- Completing the construction of `OpRead`: the args for read operation.
- Calling the `read` function provided by `Accessor`
- Wrapping the returned value as `Reader` and implementing interfaces like
`AsyncSeek`, `AsyncRead`, etc., based on `Reader`
@@ -114,11 +114,11 @@ After the completion of the Layers, it's time to call the
specific implementatio
### Service fs
-`tokio::fs::File` implements `tokio::AsyncRead` and `tokio::AsyncSeek`. Using
`async_compat::Compat`, we have transformed it into `futures::AsyncRead` and
`futures::AsyncSeek`. Based on this, we provide a built-in function
`oio::into_read_from_file` to transform it into a type that implements
`oio::Read`, with the final type name being
`oio::FromFileReader<Compat<tokio::fs::File>>`.
+`tokio::fs::File` implements `tokio::AsyncRead` and `tokio::AsyncSeek`. Using
`async_compat::Compat`, we have transformed it into `futures::AsyncRead` and
`futures::AsyncSeek`. Based on this, we provide a built-in function
`oio::into_read_from_file` to transform it into a type that implements
`oio::Read`.
There's nothing particularly complex in the implementation of
`oio::into_read_from_file`; read and seek are mostly calling the functions
provided by the incoming File type. The tricky part is about the correct
handling of seek and range: seeking to the right side of the range is allowed,
and this will not cause an error, and reading will only return empty, but
seeking to the left side of the range is illegal, and the Reader must return
`InvalidInput` for proper upper-level handling.
-> Interesting history: there was an issue in the initial implementation of
this part, discovered during fuzz testing.
+> Interesting history: there was [an
issue](https://github.com/apache/incubator-opendal/issues/2717) in the initial
implementation of this part, discovered during fuzz testing.
### Services s3