Heran Lin

> @linhr has some ideas around making sqllogictests easier to work with Here is my idea to automate the test setup, without bringing Spark as a hard dependency. 1. We...

As an update from the Sail project, we recently attracted great community interest to expand the coverage of Spark functions. Many of our community members already contributed a ton of...

Thanks @xushiyan. Would there be a possibility to keep the object_store integration and make it more pluggable? There is a similar [discussion](https://github.com/apache/iceberg-rust/issues/172) in Iceberg that shows the desire to make...

It seems this plugin is helpful for the VitePress use case:

It seems that `FileIO` internally manages `Storage` which is currently an enum. Maybe we should revisit the design of both together? The only other thing in `FileIO` is `FileIOBuilder`, which...

If we consider `FileIO` and `Storage` together, I realized that there is actually an alternative design for the IO abstraction. (This assumes that we remove `FileIOBuilder` from `FileIO`.) ```rust #[derive(Clone,...

Thanks @tustvold. Yeah the downside of `Storage` enum makes a lot of sense to me. I can see that a trait would be more extensible in general for downstream crate....

Or maybe we can have `Storage` as a trait while `FileIO` stays as a struct? (Again, I can see that the indirection is less ideal. What I was looking for...

> That's the problem, we are defining a richer interface that's not used by iceberg, then it would be confusing for people who want to define their own FileIO implementation,...

A good `FileIO`/`Storage` abstraction not only benefits object_store integration, but also makes it easier to work with OpenDAL in Iceberg. For example, I noticed that there are feature requests such...