DCjanus commented on issue #5695:
URL: https://github.com/apache/opendal/issues/5695#issuecomment-4589296897
I’m interested in trying a basic PR for this, mostly to get things moving
and to expose more concrete design questions during implementation.
Before starting, I want to share my current understanding of a possible
initial shape. This may differ from what others have in mind, so please treat
it as a starting point. I’m happy to adjust if there are better suggestions.
## Proposed initial scope
I’m currently leaning toward starting with **local OCI image layout** first,
instead of supporting remote registries or the local Docker daemon directly.
This should let us focus on the OpenDAL path model, root handling, layer
merging, whiteout behavior, and `read` / `stat` / `list` semantics.
The first version could support configuration like this:
| Option | Example | Notes |
| --- | --- | --- |
| `layout` | `/path/to/oci-layout` | Local OCI image layout directory |
| `reference` | `latest` | Required, used to select a manifest from
`index.json` |
| `platform` | `linux/amd64` | Required, to avoid implicit image selection |
| `root` | `/` | Optional, access boundary inside the image rootfs |
Then OpenDAL paths would be relative to the configured root inside the
resolved, merged filesystem. For example, with `root = "/"`:
```rust
op.read("etc/os-release").await?; // reads /etc/os-release from the image
rootfs
op.list("usr/bin/").await?;
```
With this model, `list("")` or `list("/")` would list the configured root
inside the image filesystem, not registry tags, image references, or blob paths
inside the OCI layout. Remote registries, local Docker / Podman / containerd
storage, archives, per-layer access, attestations, annotations, and SBOMs can
be left out of the first PR.
<details>
<summary>Open questions</summary>
I have a few uncertain points that I’d like to check before starting.
### Default root
My current assumption is that the default `root` should be the image rootfs
`/`, not the image `WORKDIR`, because OpenDAL’s `root` usually represents a
storage access boundary rather than a process execution context. But I’m not
sure whether others would expect different behavior here.
### URI support
I’m not planning to implement `Operator::from_uri` support in the first PR
because I don’t yet have a clear URI design in mind.
I like the transport-reference style mentioned by @NickCao, but I’m still
unsure how that model should map into an OpenDAL URI while avoiding nested
schemes like `container://docker://...`. So I’d prefer to start with
builder-based configuration first and revisit URI support once the model is
clearer.
Since this may turn out to be a larger design space than it first appears, I
may mark the initial implementation as experimental if that seems acceptable,
so we have room to adjust the config, URI shape, or metadata exposure based on
what we learn during implementation.
</details>
Does this sound like a reasonable direction for a first small PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
