RFC-1477: Remove Object Concept

[Xuanwo]

I hereby agree to the terms of the CLA available at: https://databend.rs/dev/policies/cla/

Summary

RFC: Remove Object Concept

[suyanhanx]

I think removing Object makes it difficult to accommodate some concepts.

1. What should be the scan/list result?

2. The reuse of objects will be gone.

3. The scope of Operator is too broad, and most methods are more reasonable to be placed on file/path object instances.

4. We can also provide some APIs on Operator, like blocking, as it can affect every object that is subsequently created.

And we can provide users with some best practices to let them know, for example, that creating objects incurs costs.

[Xuanwo]

1. What should be the scan/list result?

The scan/list result will be an Entry or BlockingEntry that contains the same fields as Object, but is only used for scan/list entries.

The public API should look like:

impl Entry {
    pub fn mode(&self) -> EntryType;
    pub fn path(&self) -> &str;
    pub async fn stat(&self) -> Result<Metadata>;
    pub async fn metadata(&self, key: impl Into<MetaKey>) -> Result<Metadata>;
    ...
}

The reuse of objects will be gone.

The reuse of objects will be removed since they are only a simple wrapper of Operator and a path. According to user code, almost no one reuses them. Users won't perform different actions over the same object like the following:

o.read()
o.stat()
o.read()

The scope of Operator is too broad, and most methods are more reasonable to be placed on file/path object instances.

As described in our RFC, Object is just a wrapper of Operator and a path. Removing extra abstraction will simplify the usage of OpenDAL's public API.

We can also provide some APIs on Operator, like blocking, as it can affect every object that is subsequently created.

We have a plan to provide a fn blocking(&self) -> BlockingOperator so that our users can:

let bop = op.blocking();
bop.read("path")?

[suyanhanx]

The scan/list result will be an Entry or BlockingEntry that contains the same fields as Object, but is only used for scan/list entries.
The reuse of objects will be removed since they are only a simple wrapper of Operator and a path.

So why not just keep Object?
Is it not the same as always creating an object if we remove Object and let users use something like op.read(&path)?

Even renaming Object to Entry is a good idea. 🤣

Removing extra abstraction will simplify the usage of OpenDAL's public API.

IMO, the profits aren't as substantial as anticipated.

We have a plan to provide a fn blocking(&self) -> BlockingOperator

SGTM.

[Xuanwo]

So why not just keep Object?

Do not multiply entities beyond necessity

By removing Object, we removed a core concept that users need to understand. The following code is simple (It's more like the way of std::fs and tokio::fs):

op.read("file").await?;

But this one, user may need to think:

op.object("file").read().await?;

Even renaming Object to Entry is a good idea.

Sadly, no. Object is not the same with Entry like std::fs::File is not the same with std::fs::DirEntry.

[Xuanwo]

One thing that often bothers me is that Object is an abstract concept in the storage system and cannot correspond to a physical entity. It is difficult for me to explain what it is in one sentence to users without storage background.

That why I want to delete it from OpenDAL.

[suyanhanx]

Sadly, no. Object is not the same with Entry like std::fs::File is not the same with std::fs::DirEntry.

These two comparisons don't seem to be the same thing.

(It's more like the way of std::fs and tokio::fs)

Yes, many fs do like this way.
However, I somewhat accept this RFC now.

Want to see what the community's thoughts are.

[PsiACE]

We can think of Object as an internal concept that users do not need to understand and perceive unless they have to use it.

[PsiACE]

On the whole, I admire this RFC. We can harmonize opendal’s behavior to std::fs, allowing users to utilize it with no extra cost.

[suyanhanx]

LGTM. Looking forward to it.

[ClSlaid]

A thunder of spring!