RFC-6297: Cache Layer

[koushiro]

Which issue does this PR close?

Closes #.

Rationale for this change

Propose a Cache Layer design

What changes are included in this PR?

A new RFC

Are there any user-facing changes?

[Xuanwo]

My current understanding of the cache layer is that it is a very thin component that simply wraps two (or more) OpenDAL operators. The cache policy and strategy should be defined by a separate trait. I haven't explored this idea in depth yet, but it might look something like the following:

let cache_layer = CacheLayer::builder()
    .route("*.hint", WholeCache::new(1024), memory_cache)
    .route("*.json", FixedSizeCache::new(64 << 20), memory_cache)
    .route("*.parquet", ParquetCache::new(), foyer_cache)
    .build()?;
let op = op.layer(cache_layer);

All FixedSizeCache and ParquetCache are implementations of the CachePolicy trait and can be provided by users. OpenDAL can offer some default implementations as a starting point. In other words, the cache layer itself does not make any decisions for users.

[koushiro]

My current understanding of the cache layer is that it is a very thin component that simply wraps two (or more) OpenDAL operators.

I agree，I think it's best to simplify the cache layer design first, without considering a unified cache policy and strategy design. Instead, let the corresponding OpenDAL service manage it itself. After collecting enough use cases and feedback, we can consider the design of policy/strategy and provide some common policy/strategy implementations.