opendal icon indicating copy to clipboard operation
opendal copied to clipboard
verified publisher icon apache

Apache OpenDAL 2025 Roadmap: Perfecting Production Adoption

Open Xuanwo opened this issue 9 months ago • 5 comments

We have shared our 2025 roadmap. Feel free to discuss it here.

This issue is intended to track the progress of our 2025 roadmap. Here, we will gather tracking issues for various detailed goals and provide our community with an overview of our progress.

Feel free to join the discussion on GitHub issues or in our Discord: https://opendal.apache.org/discord

OpenDAL 2025 Goal: Perfecting Production Adoption

Features Needed in Production

Core

New features in 2025:

  • [ ] context: https://github.com/apache/opendal/issues/5480 (good first issues)
  • [ ] versiong: https://github.com/apache/opendal/issues/2611
  • [ ] checksum: https://github.com/apache/opendal/issues/5549
  • [ ] caching: https://github.com/apache/opendal/issues/5678
  • [x] init_from_uri: https://github.com/apache/opendal/issues/3022

Not finished in 2024:

  • [ ] https://github.com/apache/opendal/issues/5557 (good first issues)
  • [ ] https://github.com/apache/opendal/issues/5496
  • [ ] https://github.com/apache/opendal/issues/5486 (good first issues)
  • [ ] https://github.com/apache/opendal/issues/4842
  • [x] https://github.com/apache/opendal/issues/4520
  • [ ] https://github.com/apache/opendal/issues/3922
  • [ ] https://github.com/apache/opendal/issues/3803
  • [ ] https://github.com/apache/opendal/issues/5425

Bindings

  • [ ] dart: https://github.com/apache/opendal/issues/5722
  • [x] golang: https://github.com/apache/opendal/issues/4892
  • [ ] cpp: https://github.com/apache/opendal/issues/2981
  • [ ] c: https://github.com/apache/opendal/issues/2959
  • [ ] php: https://github.com/apache/opendal/issues/2813
  • [ ] ocaml: https://github.com/apache/opendal/issues/2756
  • [ ] swift: https://github.com/apache/opendal/issues/2476
  • [ ] lua: https://github.com/apache/opendal/issues/2474

Integrations

  • [x] https://github.com/apache/opendal/issues/5015
  • [x] https://github.com/apache/opendal/issues/4786

Applications

  • [x] https://github.com/apache/opendal/issues/3782

Improvements Needed for Production

  • [x] Code Refactor
    • [x] https://github.com/apache/opendal/issues/5702 (good first issues)
    • [x] https://github.com/apache/opendal/issues/5739
    • [x] https://github.com/apache/opendal/issues/5976 (good first issues)
  • [ ] Documentation
    • [ ] https://github.com/apache/opendal/issues/4121
  • [ ] Communitation

Xuanwo avatar Mar 12 '25 12:03 Xuanwo

So many interesting issues ! We need to improve the content of tracking issues of RFC: Object Versioning https://github.com/apache/opendal/issues/2611 as some tasks aren't included. And should we include Returning metadata while reading: https://github.com/apache/opendal/issues/5425 ?

meteorgan avatar Mar 12 '25 13:03 meteorgan

So many interesting issues ! We need to improve the content of tracking issues of RFC: Object Versioning #2611 as some tasks aren't included. And should we include Returning metadata while reading: #5425 ?

Makes sense, I have updated.

Xuanwo avatar Mar 12 '25 13:03 Xuanwo

What do you think about adding documentation about service configurations?

I propose:

  • Add a "Services" section on the website. Image
  • Populate each service’s documentation from docs.md.
  • Move Rust builder-related code to each builder.

Advantages:

  • Enhanced Visibility: Developers can quickly understand which features each service supports.

  • Consistent Convention: Provides a simple, uniform approach for writing docs.md.

  • Cross-Linking: Bindings documentation can easily link to the services documentation, improving navigation and context.

Disadvantages:

  • Fragmentation: There’s a risk of documentation being split between a central services section and language-specific bindings, which might lead to inconsistencies.

  • Maintenance Overhead: Keeping the services documentation up to date in both the central section and within bindings might require extra effort.

  • Indirection Complexity: If we choose not to include service documentation in bindings, we will add an extra layer of indirection. The indirection could make navigation more confusing if not managed properly.

Open Questions:

  • How should a binding’s documentation incorporate the services documentation?

  • Will the added indirection cause usability or navigation issues?

erickguan avatar Apr 04 '25 22:04 erickguan

What do you think about adding documentation about service configurations?

We used to have something like this before, but it quickly became obsolete. These configurations can have different naming styles (access_key_id vs accessKeyId) or even different types (Duration vs int). At this point, I no longer believe this is a task that should be done manually.

In my opinion, the best approach is to have a single source of truth from which we generate configurations and comments for different bindings. Then, each binding can use its own language tools to build the API documentation.

Currently, we have an experimental code generator that can create configurations for bindings based on the Rust config. Perhaps we can build on that: https://github.com/apache/opendal/blob/main/dev/src/generate/parser.rs

Xuanwo avatar Apr 05 '25 03:04 Xuanwo

Currently, we have an experimental code generator that can create configurations for bindings based on the Rust config. Perhaps we can build on that: https://github.com/apache/opendal/blob/main/dev/src/generate/parser.rs

Looks like a good idea. I will try the parser first.

erickguan avatar Apr 05 '25 14:04 erickguan