OperatorInfo should be stored inside Operator to avoid calling metadata

[Xuanwo]

OperatorInfo will never be changed after Operator been built, we can store it inside an Arc inside Operator to avoid extra cost.

[Lzzzzzt]

If my understanding is right, it just wrap OperatorInfo in Arc<T>.

And if it is better to use OnceCell<T> for lazy init of OperatorInfo and change pub fn info(&self) -> OperatorInfo to pub fn info(&self) -> &OperatorInfo?

[Xuanwo]

Hi, @Lzzzzzt. Thanks for joining the discussion and starting #4883.

After some consideration, I think it would be better to modify Access::info() to return Arc<AccessInfo>, similiar to what you suggested in #4883 (comment). This will allow all our layers to avid extra copy.

With this change, OperatorInfo could hold an Arc<AccessInfo>, allowing the user API to remain unchanged.

[Lzzzzzt]

Hi, @Lzzzzzt. Thanks for joining the discussion and starting #4883.

After some consideration, I think it would be better to modify Access::info() to return Arc<AccessInfo>, similiar to what you suggested in #4883 (comment). This will allow all our layers to avid extra copy.

With this change, OperatorInfo could hold an Arc<AccessInfo>, allowing the user API to remain unchanged.

Ok, got it

[Lzzzzzt]

Hi, @Lzzzzzt. Thanks for joining the discussion and starting #4883.

After some consideration, I think it would be better to modify Access::info() to return Arc<AccessInfo>, similiar to what you suggested in #4883 (comment). This will allow all our layers to avid extra copy.

With this change, OperatorInfo could hold an Arc<AccessInfo>, allowing the user API to remain unchanged.

It seems need to change a lot, if modify Access::info() to return Arc<AccessInfo>

[Xuanwo]

It seems need to change a lot, if modify Access::info() to return Arc<AccessInfo>

Yes. If we do need API breaking changes, I prefer change opendal::raw API instead of opendal's public API.

[Lzzzzzt]

It seems need to change a lot, if modify Access::info() to return Arc<AccessInfo>

Yes. If we do need API breaking changes, I prefer change opendal::raw API instead of opendal's public API.

if modify Access::info() to return Arc, a lot of struct will need a extra field to store the info, is that right?

opendal/core/src/services/fs/backend.rs

Lines 184 to 210 in 740928e

	fn info(&self) -> AccessorInfo {
	let mut am = AccessorInfo::default();
	am.set_scheme(Scheme::Fs)
	.set_root(&self.core.root.to_string_lossy())
	.set_native_capability(Capability {
	stat: true,
	read: true,
	write: true,
	write_can_empty: true,
	write_can_append: true,
	write_can_multi: true,
	create_dir: true,
	delete: true,
	list: true,
	copy: true,
	rename: true,
	blocking: true,
	..Default::default()
	});
	am
	}

[Xuanwo]

if modify Access::info() to return Arc, a lot of struct will need a extra field to store the info, is that right?

We can start by simply adding an into() and refactor them later based on our feedback.

[Lzzzzzt]

some layers need a mutable AccessorInfo, so Arc<T> may not work

opendal/core/src/layers/blocking.rs

Lines 168 to 185 in 740928e

	impl<A: Access> LayeredAccess for BlockingAccessor<A> {
	type Inner = A;
	type Reader = A::Reader;
	type BlockingReader = BlockingWrapper<A::Reader>;
	type Writer = A::Writer;
	type BlockingWriter = BlockingWrapper<A::Writer>;
	type Lister = A::Lister;
	type BlockingLister = BlockingWrapper<A::Lister>;
	fn inner(&self) -> &Self::Inner {
	&self.inner
	}
	fn metadata(&self) -> AccessorInfo {
	let mut meta = self.inner.info();
	meta.full_capability_mut().blocking = true;
	meta
	}

[Xuanwo]

some layers need a mutable AccessorInfo, so Arc<T> may not work

Those layers can build a new AccessorInfo with changed value.

[Lzzzzzt]

some layers need a mutable AccessorInfo, so Arc<T> may not work

Those layers can build a new AccessorInfo with changed value.

ok

[Lzzzzzt]

I change the signature of Access::info and AccessDyn::info and related layers implement, and fs service.
PTAL