clbarnes commented on code in PR #5206:
URL: https://github.com/apache/arrow-rs/pull/5206#discussion_r1429903645
##########
object_store/src/util.rs:
##########
@@ -167,6 +172,116 @@ fn merge_ranges(ranges: &[std::ops::Range<usize>],
coalesce: usize) -> Vec<std::
ret
}
+// Fully-featured HttpRange etc. implementation here
https://github.com/clbarnes/arrow-rs/blob/httpsuff/object_store/src/util.rs
+
+/// A single range in a `Range` request.
+///
+/// These can be created from [usize] ranges, like
+///
+/// ```rust
+/// let range1: HttpRange = (50..150).into();
+/// let range2: HttpRange = (50..=150).into();
+/// let range3: HttpRange = (50..).into();
+/// let range4: HttpRange = (..150).into();
+/// ```
+///
+/// At present, this is only used internally.
+#[derive(Debug, PartialEq, Eq, Clone, Copy)]
+pub(crate) enum HttpRange {
+ /// A range with a given first and last bytes.
+ /// If `last > first`, the response should be empty.
+ Range {
Review Comment:
I think the `impl From<Range>` makes porting existing code easy enough,
could do a `impl TryInto<Range>` going the other way to complete the loop. By
renaming it from `HttpRange -> GetRange` we aren't tied so closely to the HTTP
spec so an exclusive bound would be fine.
Tuple variants all round does make construction easier, but with the
different constructors, people shouldn't need to construct variants explicitly.
I've been going back and forth about whether to have separate variants for
`::Range` and `::Offset` or whether `::Range.last` should just be optional;
having tuple structs everywhere is a good argument in favour of all separate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
