I think changing to use u64 would make sense as part of a broader initiative to support wasm32. However, given the crate currently doesn't support anything other than in memory for wasm32, I think it would be a pretty tough sell given the downstream impact of such a change. Not to mention quite hard to test.

I was running into this today as well. The axum-range crate returns a Range that's using u64 as ranges, and due to get_ranges in object_store only accepting usize, the conversion is a bit more ugly than necessary.

doesn't support anything other than in memory for wasm32

Now with OpenDAL's awesome object_store_opendal, it can support many other backends, including http, on wasm32. (cc @Xuanwo who might be interested)

I think it's worthwhile to improve wasm32 support at this point.

The next release is a major one #6903, so now is the time if anyone wants to pick this up

I understand the problem theoretically, but can someone tell me what doesn't work practically?

I ask as I was trying to verify @XiangpengHao 's nice PR to make this change:

• Switch to use u64 range instead of usize, for better wasm32 support #6961 (review)

But I found I could run the tests / build for object_store on wasm32 just fine 🤔

what doesn't work practically?

My use case is that when trying to load hits.parquet (15GB) into browser-based parquet-viewer, it will fail to read the correct file range, because the file size is larger than what usize on wasm32 (essentially u32) can represent. To allow larger than 4GB ranges, we need to use u64 instead of usize to represent ranges.

For example: range 0xffff_ffff_ffff_0000 - 0xffff_ffff_ffff_ffff will essentially become 0xffff_0000 - 0xffff_ffff on wasm32

tests / build for object_store on wasm32 just fine

I think this is because we don't have test cases for large ranges.