Module rfcs

Available on docsrs only.

RFCs - OpenDAL Active RFC List

RFCs power OpenDAL’s development.

The “RFC” (request for comments) process is intended to provide a consistent and controlled path for changes to OpenDAL (such as new features) so that all stakeholders can be confident about the direction of the project.

Many changes, including bug fixes and documentation improvements, can be implemented and reviewed via the normal GitHub pull request workflow.

Some changes, though, are “substantial” and we ask that these be put through a bit of a design process and produce a consensus among the OpenDAL community.

Which kinds of changes require an RFC?

Any substantial change or addition to the project that would require a significant amount of work to implement should generally be an RFC.

Some examples include:

• A new feature that creates a new public API or raw API.
• The removal of features that already shipped as part of the release.
• A big refactor of existing code or reorganization of code into new modules.

Those are just a few examples. Ultimately, the judgment call of what constitutes a big enough change to warrant an RFC is left to the project maintainers.

If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first.

Before creating the RFC

Preparing in advance before submitting an RFC hastily can increase its chances of being accepted. If you have proposals to make, it is advisable to engage in some preliminary groundwork to facilitate a smoother process.

It is great to seek feedback from other project developers first, as this can help validate the viability of the RFC. To ensure a sustained impact on the project, it is important to work together and reach a consensus.

Common preparatory steps include presenting your idea on platforms such as GitHub issues or discussions, or engaging in discussions through our email list or Discord server.

The RFC process

• Fork the OpenDAL repo and create your branch from main.
• Copy [0000_example.md] to 0000-my-feature.md (where “my-feature” is descriptive). Don’t assign an RFC number yet; This is going to be the PR number, and we’ll rename the file accordingly if the RFC is accepted.
• Submit a pull request. As a pull request, the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response.
• Now that your RFC has an open pull request, use the issue number of this PR to update your 0000- prefix to that number.
• Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don’t receive any comments. Feel free to reach OpenDAL maintainers for help.
• RFCs rarely go through this process unchanged, especially as alternatives and drawbacks are shown. You can make edits, big and small, to the RFC to clarify or change the design, but make changes as new commits to the pull request, and leave a comment on the pull request explaining your changes. Specifically, do not squash or rebase commits after they are visible on the pull request.
• The RFC pull request lasts for three days after the last update. After that, the RFC will be accepted or declined based on the consensus reached in the discussion.
• For the accepting of an RFC, we will require approval from at least three maintainers.
• Once the RFC is accepted, please create a tracking issue and update links in RFC. And then the PR will be merged and the RFC will become ‘active’ status.

Implementing an RFC

An active RFC does not indicate the priority assigned to its implementation, nor does it imply that a developer has been specifically assigned the task of implementing the feature.

The RFC author is encouraged to submit an implementation after the RFC has been accepted. Nevertheless, it is not obligatory for them to do so.

Accepted RFCs may represent features that can wait until a developer chooses to work on them. Each accepted RFC is associated with an issue in the OpenDAL repository, which tracks its implementation.

If you are interested in implementing an RFC but are unsure if someone else is already working on it, feel free to inquire by leaving a comment on the associated issue.

Some useful tips

• The author of an RFC may not be the same one as the implementer. Therefore, when submitting an RFC, it is advisable to include sufficient information.
• If modifications are needed for an accepted RFC, please submit a new pull request or create a new RFC to propose changes.

Modules

rfc_0000_example

RFC example

rfc_0041_object_native_api

Object native API

rfc_0044_error_handle

Error handle

rfc_0057_auto_region

Auto region

rfc_0069_object_stream

Object stream

rfc_0090_limited_reader

Limited reader

rfc_0112_path_normalization

Path normalization

rfc_0191_async_streaming_io

Async streaming IO

rfc_0203_remove_credential

Remove credential

rfc_0221_create_dir

Create dir

rfc_0247_retryable_error

Retryable error

rfc_0293_object_id

Object ID

rfc_0337_dir_entry

Dir entry

rfc_0409_accessor_capabilities

Accessor capabilities

rfc_0413_presign

Presign

rfc_0423_command_line_interface

Command line interface

rfc_0429_init_from_iter

Init from iter

rfc_0438_multipart

Multipart

rfc_0443_gateway

Gateway

rfc_0501_new_builder

New builder

rfc_0554_write_refactor

Write refactor

rfc_0561_list_metadata_reuse

List metadata reuse

rfc_0599_blocking_api

Blocking API

rfc_0623_redis_service

Redis service

rfc_0627_split_capabilities

Split capabilities

rfc_0661_path_in_accessor

Path in accessor

rfc_0793_generic_kv_services

Generic KV services

rfc_0926_object_reader

Object reader

rfc_0977_refactor_error

Refactor error

rfc_1085_object_handler

Object handler

rfc_1391_object_metadataer

Object metadataer

rfc_1398_query_based_metadata

Query based metadata

rfc_1420_object_writer

Object writer

rfc_1477_remove_object_concept

Remove object concept

rfc_1735_operation_extension

Operation extension

rfc_2083_writer_sink_api

Writer sink API

rfc_2133_append_api

Append API

rfc_2299_chain_based_operator_api

Chain based operator API

rfc_2602_object_versioning

Object versioning

rfc_2758_merge_append_into_write

Merge append into write

rfc_2774_lister_api

Lister API

rfc_2779_list_with_metakey

List with metakey

rfc_2852_native_capability

Native capability

rfc_3017_remove_write_copy_from

Remove write copy from

rfc_3197_config

Config

rfc_3232_align_list_api

Align list API

rfc_3243_list_prefix

List prefix

rfc_3356_lazy_reader

Lazy reader

rfc_3526_list_recursive

List recursive

rfc_3574_concurrent_stat_in_list

Concurrent stat in list

rfc_3734_buffered_reader

Buffered Reader

rfc_3898_concurrent_writer

Concurrent Writer

rfc_3911_deleter_api

Deleter API

rfc_4382_range_based_read

Range Based Read API

rfc_4638_executor

Executor API

rfc_5314_remove_metakey

Remove metakey

rfc_5444_operator_from_uri

Operator from uri

rfc_5479_context

Context

rfc_5485_conditional_reader

Conditional Reader

rfc_5495_list_with_deleted

List With Deleted

rfc_5556_write_returns_metadata

Write Returns Metadata

rfc_5871_read_returns_metadata

Read Returns Metadata

rfc_6189_remove_native_blocking

Remove Native Blocking

rfc_6209_glob_support

Glob support

rfc_6213_options_api

Options API