Feature Description
Thought of a few Lister and Entry enhancements for your consideration.
(Affects public API)
Problem and Solution
stat returns Metadata which is okay, and Lister returns an Entry which is path +Metadata. But since Lister doesn't guarantee metadata retrieval due to performance implications, and Entry should be path +Option<Metadata> instead.
- Some user might still be ready for those performance cost, and for this
ListOptions should have a key with_metadata: bool which ensures the metadata retrieval. This way the user decides performance vs results.
(they can still do this with an external stat call but user side code simplifies with this simple new option).
- Additionally,
stat already has some options which might be useful in Lister as well (can be pushed down, if backend services support it),
- if_match
- if_none_match
- if_modified_since
- if_unmodified_since
- Suggestions for better naming,
deleted -> with_deleted
versions -> with_versions
what do you think?
Additional Context
No response
Are you willing to contribute to the development of this feature?
Feature Description
Thought of a few
ListerandEntryenhancements for your consideration.(Affects public API)
Problem and Solution
statreturnsMetadatawhich is okay, andListerreturns anEntrywhich is path +Metadata. But sinceListerdoesn't guarantee metadata retrieval due to performance implications, and Entry should be path +Option<Metadata>instead.ListOptionsshould have a keywith_metadata: boolwhich ensures the metadata retrieval. This way the user decides performance vs results.(they can still do this with an external
statcall but user side code simplifies with this simple new option).statalready has some options which might be useful inListeras well (can be pushed down, if backend services support it),deleted->with_deletedversions->with_versionswhat do you think?
Additional Context
No response
Are you willing to contribute to the development of this feature?