opendal 0.1.6.pre.rc.1-arm64-darwin-23

data/core/src/docs/rfcs/0090_limited_reader.md

@@ -0,0 +1,155 @@
+- Proposal Name: `limited_reader`
+- Start Date: 2022-03-02
+- RFC PR: [apache/opendal#0090](https://github.com/apache/opendal/pull/0090)
+- Tracking Issue: [apache/opendal#0090](https://github.com/apache/opendal/issues/0090)
+
+# Summary
+
+Native support for the limited reader.
+
+# Motivation
+
+In proposal [object-native-api](./0041-object-native-api.md) we introduced `Reader`, in which we will send request like:
+
+```rust
+let op = OpRead {
+    path: self.path.to_string(),
+    offset: Some(self.current_offset()),
+    size: None,
+};
+```
+
+In this implementation, we depend on the HTTP client to drop the request when we stop reading. However, we always read too much extra data, which decreases our reading performance.
+
+Here is a benchmark around reading the whole file and only reading half:
+
+```txt
+s3/read/1c741003-40ef-43a9-b23f-b6a32ed7c4c6
+                        time:   [7.2697 ms 7.3521 ms 7.4378 ms]
+                        thrpt:  [2.1008 GiB/s 2.1252 GiB/s 2.1493 GiB/s]
+s3/read_half/1c741003-40ef-43a9-b23f-b6a32ed7c4c6
+                        time:   [7.0645 ms 7.1524 ms 7.2473 ms]
+                        thrpt:  [1.0780 GiB/s 1.0923 GiB/s 1.1059 GiB/s]
+```
+
+So our current behavior is buggy, and we need more clear API to address that.
+
+# Guide-level explanation
+
+We will remove `Reader::total_size()` from public API instead of adding the following APIs for `Object`:
+
+```rust
+pub fn reader(&self) -> Reader {}
+pub fn range_reader(&self, offset: u64, size: u64) -> Reader {}
+pub fn offset_reader(&self, offset: u64) -> Reader {}
+pub fn limited_reader(&self, size: u64) -> Reader {}
+```
+
+- `reader`: returns a new reader who can read the whole file.
+- `range_reader`: returns a ranged reader which read `[offset, offset+size)`.
+- `offset_reader`: returns a reader from offset `[offset:]`
+- `limited_reader`: returns a limited reader `[:size]`
+
+Take `parquet`'s actual logic as an example. We can rewrite:
+
+```rust
+async fn _read_single_column_async<'b, R, F>(
+    factory: F,
+    meta: &ColumnChunkMetaData,
+) -> Result<(&ColumnChunkMetaData, Vec<u8>)>
+where
+    R: AsyncRead + AsyncSeek + Send + Unpin,
+    F: Fn() -> BoxFuture<'b, std::io::Result<R>>,
+{
+    let mut reader = factory().await?;
+    let (start, len) = meta.byte_range();
+    reader.seek(std::io::SeekFrom::Start(start)).await?;
+    let mut chunk = vec![0; len as usize];
+    reader.read_exact(&mut chunk).await?;
+    Result::Ok((meta, chunk))
+}
+```
+
+into
+
+```rust
+async fn _read_single_column_async<'b, R, F>(
+    factory: F,
+    meta: &ColumnChunkMetaData,
+) -> Result<(&ColumnChunkMetaData, Vec<u8>)>
+where
+    R: AsyncRead + AsyncSeek + Send + Unpin,
+    F: Fn(usize, usize) -> BoxFuture<'b, std::io::Result<R>>,
+{
+    let (start, len) = meta.byte_range();
+    let mut reader = factory(start, len).await?;
+    let mut chunk = vec![0; len as usize];
+    reader.read_exact(&mut chunk).await?;
+    Result::Ok((meta, chunk))
+}
+```
+
+So that:
+
+- No extra data will be read.
+- No extra `seek`/`stat` operation is needed.
+
+# Reference-level explanation
+
+Inside `Reader`, we will correctly maintain `offset`, `size`, and `pos`.
+
+- If `offset` is `None`, we will use `0` instead.
+- If `size` is `None`, we will use `meta.content_length() - self.offset.unwrap_or_default()` instead.
+
+We will calculate `Reader` current offset and size easily:
+
+```rust
+fn current_offset(&self) -> u64 {
+    self.offset.unwrap_or_default() + self.pos
+}
+
+fn current_size(&self) -> Option<u64> {
+    self.size.map(|v| v - self.pos)
+}
+```
+
+Instead of constantly requesting the entire object content, we will set the size:
+
+```rust
+let op = OpRead {
+    path: self.path.to_string(),
+    offset: Some(self.current_offset()),
+    size: self.current_size(),
+};
+```
+
+After this change, we will have a similar throughput for `read_all` and `read_half`:
+
+```txt
+s3/read/6dd40f8d-7455-451e-b510-3b7ac23e0468
+                        time:   [4.9554 ms 5.0888 ms 5.2282 ms]
+                        thrpt:  [2.9886 GiB/s 3.0704 GiB/s 3.1532 GiB/s]
+s3/read_half/6dd40f8d-7455-451e-b510-3b7ac23e0468
+                        time:   [3.1868 ms 3.2494 ms 3.3052 ms]
+                        thrpt:  [2.3637 GiB/s 2.4043 GiB/s 2.4515 GiB/s]
+```
+
+# Drawbacks
+
+None
+
+# Rationale and alternatives
+
+None
+
+# Prior art
+
+None
+
+# Unresolved questions
+
+None
+
+# Future possibilities
+
+- Refactor the parquet reading logic to make the most use of `range_reader`.

data/core/src/docs/rfcs/0112_path_normalization.md

@@ -0,0 +1,79 @@
+- Proposal Name: `path-normalization`
+- Start Date: 2022-03-08
+- RFC PR: [apache/opendal#112](https://github.com/apache/opendal/pull/112)
+- Tracking Issue: [apache/opendal#112](https://github.com/apache/opendal/issues/112)
+
+# Summary
+
+Implement path normalization to enhance user experience.
+
+# Motivation
+
+OpenDAL's current path behavior makes users confused:
+
+- [operator.object("/admin/data/") error](https://github.com/apache/opendal/issues/107)
+- [Read /admin/data//ontime_200.csv return empty](https://github.com/apache/opendal/issues/109)
+
+They are different bugs that reflect the exact root cause: the path is not well normalized.
+
+On local fs, we can read the same path with different path: `abc/def/../def`, `abc/def`, `abc//def`, `abc/./def`.
+
+There is no magic here: our stdlib does the dirty job. For example:
+
+- [std::path::PathBuf::canonicalize](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.canonicalize): Returns the canonical, absolute form of the path with all intermediate components normalized and symbolic links resolved.
+- [std::path::PathBuf::components](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.components): Produces an iterator over the Components of the path. When parsing the path, there is a small amount of normalization...
+
+But for s3 alike storage system, there's no such helpers: `abc/def/../def`, `abc/def`, `abc//def`, `abc/./def` refers entirely different objects. So users may confuse why I can't get the object with this path.
+
+So OpenDAL needs to implement path normalization to enhance the user experience.
+
+# Guide-level explanation
+
+We will do path normalization automatically.
+
+The following rules will be applied (so far):
+
+- Remove `//` inside path: `op.object("abc/def")` and `op.object("abc//def")` will resolve to the same object.
+- Make sure path under `root`: `op.object("/abc")` and `op.object("abc")` will resolve to the same object.
+
+Other rules still need more consideration to leave them for the future.
+
+# Reference-level explanation
+
+We will build the absolute path via `{root}/{path}` and replace all `//` into `/` instead.
+
+# Drawbacks
+
+None
+
+# Rationale and alternatives
+
+## How about the link?
+
+If we build an actual path via `{root}/{path}`, the link object may be inaccessible.
+
+I don't have good ideas so far. Maybe we can add a new flag to control the link behavior. For now, there's no feature request for link support.
+
+Let's leave for the future to resolve.
+
+## S3 URI Clean
+
+For s3, `abc//def` is different from `abc/def` indeed. To make it possible to access not normalized path, we can provide a new flag for the builder:
+
+```rust
+let builder = Backend::build().disable_path_normalization()
+```
+
+In this way, the user can control the path more precisely.
+
+# Prior art
+
+None
+
+# Unresolved questions
+
+None
+
+# Future possibilities
+
+None

data/core/src/docs/rfcs/0191_async_streaming_io.md

@@ -0,0 +1,328 @@
+- Proposal Name: `async_streaming_io`
+- Start Date: 2022-03-28
+- RFC PR: [apache/opendal#191](https://github.com/apache/opendal/pull/191)
+- Tracking Issue: [apache/opendal#190](https://github.com/apache/opendal/issues/190)
+
+**Reverted**
+
+# Summary
+
+Use `Stream`/`Sink` instead of `AsyncRead` in `Accessor`.
+
+# Motivation
+
+`Accessor` intends to be the `underlying trait of all backends for implementers`. However, it's not so underlying enough.
+
+## Over-wrapped
+
+`Accessor` returns a `BoxedAsyncReader` for `read` operation:
+
+```rust
+pub type BoxedAsyncReader = Box<dyn AsyncRead + Unpin + Send>;
+
+pub trait Accessor {
+    async fn read(&self, args: &OpRead) -> Result<BoxedAsyncReader> {
+        let _ = args;
+        unimplemented!()
+    }
+}
+```
+
+And we are exposing `Reader`, which implements `AsyncRead` and `AsyncSeek` to end-users. For every call to `Reader::poll_read()`, we need:
+
+- `Reader::poll_read()`
+- `BoxedAsyncReader::poll_read()`
+- `IntoAsyncRead<ByteStream>::poll_read()`
+- `ByteStream::poll_next()`
+
+If we could return a `Stream` directly, we can transform the call stack into:
+
+- `Reader::poll_read()`
+- `ByteStream::poll_next()`
+
+In this way, we operate on the underlying IO stream, and the caller must keep track of the reading states.
+
+## Inconsistent
+
+OpenDAL's `read` and `write` behavior is not consistent.
+
+```rust
+pub type BoxedAsyncReader = Box<dyn AsyncRead + Unpin + Send>;
+
+pub trait Accessor: Send + Sync + Debug {
+    async fn read(&self, args: &OpRead) -> Result<BoxedAsyncReader> {
+        let _ = args;
+        unimplemented!()
+    }
+    async fn write(&self, r: BoxedAsyncReader, args: &OpWrite) -> Result<usize> {
+        let (_, _) = (r, args);
+        unimplemented!()
+    }
+}
+```
+
+For `read`, OpenDAL returns a `BoxedAsyncReader` which users can decide when and how to read data. But for `write`, OpenDAL accepts a `BoxedAsyncReader` instead, in which users can't control the writing logic. How large will the writing buffer size be? When to call `flush`?
+
+## Service native optimization
+
+OpenDAL knows more about the service detail, but returning `BoxedAsyncReader` makes it can't fully use the advantage.
+
+For example, most object storage services use HTTP to transfer data which is TCP stream-based. The most efficient way is to return a full TCP buffer, but users don't know about that. First, users could have continuous small reads on stream. To overcome the poor performance, they have to use `BufReader`, which adds a new buffering between reading. Then, users don't know the correct (best) buffer size to set.
+
+Via returning a `Stream`, users could benefit from it in both ways:
+
+- Users who want underlying control can operate on the `Stream` directly.
+- Users who don't care about the behavior can use OpenDAL provided Reader, which always adopts the best optimization.
+
+# Guide-level explanation
+
+Within the `async_streaming_io` feature, we will add the following new APIs to `Object`:
+
+```rust
+impl Object {
+    pub async fn stream(&self, offset: Option<u64>, size: Option<u64>) -> Result<BytesStream> {}
+    pub async fn sink(&self, size: u64) -> Result<BytesSink> {}
+}
+```
+
+Users can control the underlying logic of those bytes, streams, and sinks.
+
+For example, they can:
+
+- Read data on demand: `stream.next().await`
+- Write data on demand: `sink.feed(bs).await; sink.close().await;`
+
+Based on `stream` and `sink`, `Object` will provide more optimized helper functions like:
+
+- `async read(offset: Option<u64>, size: Option<u64>) -> Result<bytes::Bytes>`
+- `async write(bs: bytes::Bytes) -> Result<()>`
+
+# Reference-level explanation
+
+`read` and `write` in `Accessor` will be refactored into streaming-based:
+
+```rust
+pub type BytesStream =  Box<dyn Stream + Unpin + Send>;
+pub type BytesSink =  Box<dyn Sink + Unpin + Send>;
+
+pub trait Accessor: Send + Sync + Debug {
+    async fn read(&self, args: &OpRead) -> Result<BytesStream> {
+        let _ = args;
+        unimplemented!()
+    }
+    async fn write(&self, args: &OpWrite) -> Result<BytesSink> {
+        let _ = args;
+        unimplemented!()
+    }
+}
+```
+
+All other IO functions will be adapted to fit these changes.
+
+For fs, it's simple to implement `Stream` and `Sink` for `tokio::fs::File`.
+
+We will return a `BodySinker` instead for all HTTP-based storage services. In which we maintain a `put_object` `ResponseFuture` that construct by `hyper` and a `sender` part of the channel. All data sent by users will be passed to `ResponseFuture` via the unbuffered channel.
+
+```rust
+struct BodySinker {
+    fut: ResponseFuture,
+    sender: Sender<bytes::Bytes>
+}
+```
+
+# Drawbacks
+
+## Performance regression on fs
+
+`fs` is not stream based backend, and convert from `Reader` to `Stream` is not zero cost. Based on benchmark over `IntoStream`, we can get nearly 70% performance drawback (pure memory):
+
+```rust
+into_stream/into_stream time:   [1.3046 ms 1.3056 ms 1.3068 ms]
+                        thrpt:  [2.9891 GiB/s 2.9919 GiB/s 2.9942 GiB/s]
+into_stream/raw_reader  time:   [382.10 us 383.52 us 385.16 us]
+                        thrpt:  [10.142 GiB/s 10.185 GiB/s 10.223 GiB/s]
+```
+
+However, real fs is not as fast as memory and most overhead will happen at disk side, so that performance regression is allowed (at least at this time).
+
+# Rationale and alternatives
+
+## Performance for switching from Reader to Stream
+
+Before
+
+```rust
+read_full/4.00 KiB      time:   [455.70 us 466.18 us 476.93 us]
+                        thrpt:  [8.1904 MiB/s 8.3794 MiB/s 8.5719 MiB/s]
+read_full/256 KiB       time:   [530.63 us 544.30 us 557.84 us]
+                        thrpt:  [448.16 MiB/s 459.30 MiB/s 471.14 MiB/s]
+read_full/4.00 MiB      time:   [1.5569 ms 1.6152 ms 1.6743 ms]
+                        thrpt:  [2.3330 GiB/s 2.4184 GiB/s 2.5090 GiB/s]
+read_full/16.0 MiB      time:   [5.7337 ms 5.9087 ms 6.0813 ms]
+                        thrpt:  [2.5693 GiB/s 2.6444 GiB/s 2.7251 GiB/s]
+```
+
+After
+
+```rust
+read_full/4.00 KiB      time:   [455.67 us 466.03 us 476.21 us]
+                        thrpt:  [8.2027 MiB/s 8.3819 MiB/s 8.5725 MiB/s]
+                 change:
+                        time:   [-2.1168% +0.6241% +3.8735%] (p = 0.68 > 0.05)
+                        thrpt:  [-3.7291% -0.6203% +2.1625%]
+                        No change in performance detected.
+read_full/256 KiB       time:   [521.04 us 535.20 us 548.74 us]
+                        thrpt:  [455.59 MiB/s 467.11 MiB/s 479.81 MiB/s]
+                 change:
+                        time:   [-7.8470% -4.7987% -1.4955%] (p = 0.01 < 0.05)
+                        thrpt:  [+1.5182% +5.0406% +8.5152%]
+                        Performance has improved.
+read_full/4.00 MiB      time:   [1.4571 ms 1.5184 ms 1.5843 ms]
+                        thrpt:  [2.4655 GiB/s 2.5725 GiB/s 2.6808 GiB/s]
+                 change:
+                        time:   [-5.4403% -1.5696% +2.3719%] (p = 0.44 > 0.05)
+                        thrpt:  [-2.3170% +1.5946% +5.7533%]
+                        No change in performance detected.
+read_full/16.0 MiB      time:   [5.0201 ms 5.2105 ms 5.3986 ms]
+                        thrpt:  [2.8943 GiB/s 2.9988 GiB/s 3.1125 GiB/s]
+                 change:
+                        time:   [-15.917% -11.816% -7.5219%] (p = 0.00 < 0.05)
+                        thrpt:  [+8.1337% +13.400% +18.930%]
+                        Performance has improved.
+```
+
+## Performance for the extra channel in `write`
+
+Based on the benchmark during research, the **unbuffered** channel does improve the performance a bit in some cases:
+
+Before:
+
+```rust
+write_once/4.00 KiB     time:   [564.11 us 575.17 us 586.15 us]
+                        thrpt:  [6.6642 MiB/s 6.7914 MiB/s 6.9246 MiB/s]
+write_once/256 KiB      time:   [1.3600 ms 1.3896 ms 1.4168 ms]
+                        thrpt:  [176.46 MiB/s 179.90 MiB/s 183.82 MiB/s]
+write_once/4.00 MiB     time:   [11.394 ms 11.555 ms 11.717 ms]
+                        thrpt:  [341.39 MiB/s 346.18 MiB/s 351.07 MiB/s]
+write_once/16.0 MiB     time:   [41.829 ms 42.645 ms 43.454 ms]
+                        thrpt:  [368.20 MiB/s 375.19 MiB/s 382.51 MiB/s]
+```
+
+After:
+
+```rust
+write_once/4.00 KiB     time:   [572.20 us 583.62 us 595.21 us]
+                        thrpt:  [6.5628 MiB/s 6.6932 MiB/s 6.8267 MiB/s]
+                 change:
+                        time:   [-6.3126% -3.8179% -1.0733%] (p = 0.00 < 0.05)
+                        thrpt:  [+1.0849% +3.9695% +6.7380%]
+                        Performance has improved.
+write_once/256 KiB      time:   [1.3192 ms 1.3456 ms 1.3738 ms]
+                        thrpt:  [181.98 MiB/s 185.79 MiB/s 189.50 MiB/s]
+                 change:
+                        time:   [-0.5899% +1.7476% +4.1037%] (p = 0.15 > 0.05)
+                        thrpt:  [-3.9420% -1.7176% +0.5934%]
+                        No change in performance detected.
+write_once/4.00 MiB     time:   [10.855 ms 11.039 ms 11.228 ms]
+                        thrpt:  [356.25 MiB/s 362.34 MiB/s 368.51 MiB/s]
+                 change:
+                        time:   [-6.9651% -4.8176% -2.5681%] (p = 0.00 < 0.05)
+                        thrpt:  [+2.6358% +5.0614% +7.4866%]
+                        Performance has improved.
+write_once/16.0 MiB     time:   [38.706 ms 39.577 ms 40.457 ms]
+                        thrpt:  [395.48 MiB/s 404.27 MiB/s 413.37 MiB/s]
+                 change:
+                        time:   [-10.829% -8.3611% -5.8702%] (p = 0.00 < 0.05)
+                        thrpt:  [+6.2363% +9.1240% +12.145%]
+                        Performance has improved.
+```
+
+## Add complexity on the services side
+
+Returning `Stream` and `Sink` make it complex to implement. At first glance, it does. But in reality, it's not.
+
+Note: HTTP (especially for hyper) is stream-oriented.
+
+- Returning a `stream` is more straightforward than `reader`.
+- Returning `Sink` is covered by the global shared `BodySinker` struct.
+
+Other helper functions will be covered at the Object-level which services don't need to bother.
+
+# Prior art
+
+## Returning a `Writer`
+
+The most natural extending is to return `BoxedAsyncWriter`:
+
+```rust
+pub trait Accessor: Send + Sync + Debug {
+    /// Read data from the underlying storage into input writer.
+    async fn read(&self, args: &OpRead) -> Result<BoxedAsyncReader> {
+        let _ = args;
+        unimplemented!()
+    }
+    /// Write data from input reader to the underlying storage.
+    async fn write(&self, args: &OpWrite) -> Result<BoxedAsyncWriter> {
+        let _ = args;
+        unimplemented!()
+    }
+}
+```
+
+But it only fixes the `Inconsistent` concern and can't help with other issues.
+
+## Slice based API
+
+Most rust IO APIs are based on slice:
+
+```rust
+pub trait Accessor: Send + Sync + Debug {
+    /// Read data from the underlying storage into input writer.
+    async fn read(&self, args: &OpRead, bs: &mut [u8]) -> Result<usize> {
+        let _ = args;
+        unimplemented!()
+    }
+    /// Write data from input reader to the underlying storage.
+    async fn write(&self, args: &OpWrite, bs: &[u8]) -> Result<usize> {
+        let _ = args;
+        unimplemented!()
+    }
+}
+```
+
+The problem is `Accessor` doesn't have states:
+
+- If we require all data must be passed at one time, we can't support large files read & write
+- If we allow users to call `read`/`write` multiple times, we need to implement another `Reader` and `Writer` alike logic.
+
+## Accept `Reader` and `Writer`
+
+It's also possible to accept `Reader` and `Writer` instead.
+
+```rust
+pub trait Accessor: Send + Sync + Debug {
+    /// Read data from the underlying storage into input writer.
+    async fn read(&self, args: &OpRead, w: BoxedAsyncWriter) -> Result<usize> {
+        let _ = args;
+        unimplemented!()
+    }
+    /// Write data from input reader to the underlying storage.
+    async fn write(&self, args: &OpWrite, r: BoxedAsyncReader) -> Result<usize> {
+        let _ = args;
+        unimplemented!()
+    }
+}
+```
+
+This API design addressed all concerns but made it hard for users to use. Primarily, we can't support `futures::AsyncRead` and `tokio::AsyncRead` simultaneously.
+
+For example, we can't accept a `Box::new(Vec::new())`, user can't get this vec from OpenDAL.
+
+# Unresolved questions
+
+None.
+
+# Future possibilities
+
+- Implement `Object::read_into(w: BoxedAsyncWriter)`
+- Implement `Object::write_from(r: BoxedAsyncReader)`

data/core/src/docs/rfcs/0203_remove_credential.md

@@ -0,0 +1,96 @@
+- Proposal Name: `remove_credential`
+- Start Date: 2022-04-02
+- RFC PR: [apache/opendal#203](https://github.com/apache/opendal/pull/203)
+- Tracking Issue: [apache/opendal#203](https://github.com/apache/opendal/issues/203)
+
+# Summary
+
+Remove the concept of credential.
+
+# Motivation
+
+`Credential` intends to carry service credentials like `access_key_id` and `secret_access_key`. At OpenDAL, we designed a global `Credential` enum for services and users to use.
+
+```rust
+pub enum Credential {
+    /// Plain refers to no credential has been provided, fallback to services'
+    /// default logic.
+    Plain,
+    /// Basic refers to HTTP Basic Authentication.
+    Basic { username: String, password: String },
+    /// HMAC, also known as Access Key/Secret Key authentication.
+    HMAC {
+        access_key_id: String,
+        secret_access_key: String,
+    },
+    /// Token refers to static API token.
+    Token(String),
+}
+```
+
+However, every service only supports one kind of `Credential` with different `Credential` load methods covered by [reqsign](https://github.com/Xuanwo/reqsign). As a result, only `HMAC` is used. Both users and services need to write the same logic again and again.
+
+# Guide-level explanation
+
+`Credential` will be removed, and the services builder will provide native credential representation directly.
+
+For s3:
+
+```rust
+pub fn access_key_id(&mut self, v: &str) -> &mut Self {}
+pub fn secret_access_key(&mut self, v: &str) -> &mut Self {}
+```
+
+For azblob:
+
+```rust
+pub fn account_name(&mut self, account_name: &str) -> &mut Self {}
+pub fn account_key(&mut self, account_key: &str) -> &mut Self {}
+```
+
+All builders must implement `Debug` by hand and redact sensitive fields to avoid credentials being a leak.
+
+```rust
+impl Debug for Builder {
+    fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result {
+        let mut ds = f.debug_struct("Builder");
+
+        ds.field("root", &self.root);
+        ds.field("container", &self.container);
+        ds.field("endpoint", &self.endpoint);
+
+        if self.account_name.is_some() {
+            ds.field("account_name", &"<redacted>");
+        }
+        if self.account_key.is_some() {
+            ds.field("account_key", &"<redacted>");
+        }
+
+        ds.finish_non_exhaustive()
+    }
+}
+```
+
+# Reference-level explanation
+
+Simple change without reference-level explanation needs.
+
+# Drawbacks
+
+API Breakage.
+
+# Rationale and alternatives
+
+None
+
+# Prior art
+
+None
+
+# Unresolved questions
+
+None
+
+# Future possibilities
+
+None