Tracking Issues of RFC-5556: Write Returns Metadata

[meteorgan]

• RFC: https://github.com/apache/opendal/pull/5556

Tasks

1. https://github.com/apache/opendal/pull/5562
   • [x] modify struct Operator to return Result<Metadata> instead of Result<()> for write and write_with functions
   • [x] modify struct Writer to return Result<Metadata> instead of Result<()> for the close() function
   • [x] modify oio::Write trait to return Result<Metadata> instead of Result<()> for the close() function
   • [x] modify oio::MultipartWrite trait to return Result<Metadata> instead of Result<()> for the complete_part() and write_once functions
   • [x] add behavior tests
   • [x] implement the logic for some services
     • [x] s3
     • [x] fs
     • [x] monoiofs
2. implement the logic of returning metadata after writing for other services: #5693

[meteorgan]

I'll take on tasks 1 through 5 and implement the logic for S3.

[Xuanwo]

Hi, @meteorgan, could you create an issue similar to this one: https://github.com/apache/opendal/issues/5677?

Also, could you create an example PR to make it easier for our contributors to follow?

[meteorgan]

Hi, @meteorgan, could you create an issue similar to this one: #5677?

Also, could you create an example PR to make it easier for our contributors to follow?

Sure, I'll take care of it later.

[Xuanwo]

Hi, @meteorgan, I used to believe that write_has_xxx was a good idea, but after reviewing PRs and using this API in practice, I found it confusing and not particularly useful.

What do you think about simply removing those capabilities and not requiring services to configure them? After this change, we only need to ensure that if this field exists, it matches the stat's result.

This also makes https://github.com/apache/opendal/issues/5425 easier to implement, as we no longer need an additional set of read_has_xxx.

The stat_has_xxx and list_has_xxx functions are also worth considering if we need to remove them. There are no users use them at all: https://github.com/search?q=stat_has_etag&type=code

[meteorgan]

Hi, @meteorgan, I used to believe that write_has_xxx was a good idea, but after reviewing PRs and using this API in practice, I found it confusing and not particularly useful.

The stat_has_xxx and list_has_xxx functions are also worth considering if we need to remove them. There are no users use them at all: https://github.com/search?q=stat_has_etag&type=code

I reckon these capabilities aren't meant for users, they are more for internal use. We leverage them to improve testing and figure out what the services are capable of.

[Xuanwo]

I reckon these capabilities aren't meant for users, they are more for internal use. We leverage them to improve testing and figure out what the services are capable of.

They are currently exposed as a public API. If our purpose has changed, we may need to design a new API for this.

[meteorgan]

They are currently exposed as a public API. If our purpose has changed, we may need to design a new API for this.

Yeah, maybe simply keeping them out of the public APIs is sufficient. I have another question: are capabilities like xx_with_xx commonly used by users?

[Xuanwo]

I have another question: are capabilities like xx_with_xx commonly used by users?

I'm guessing no. The only known users are our bindings.