Support random access to Binary resources via the BinaryService

[acoburn]

The BinaryService interface offers a single method for fetching resources:

Optional<InputStream> get(IRI);

In the case where a client requests a partial resource (via Range header requests), the HTTP layer currently requests the entire Binary as an InputStream, and it then drops any non-relevant segments. While this works, it is not efficient for very, very large binaries which may be partitioned into multiple blocks across different storage locations. It would be much more flexible to extend this method into something like:

Optional<InputStream> get(IRI, Range...);

Where Range could be a type such as a pair of Integers. Or perhaps there is an appropriate built-in type or something from a Commons library. Or it may be necessary to add a new type to the Trellis API (or better: generalize an existing type, such as o.t.api.VersionRange).

I am suggesting here a variable number of Range objects since the HTTP specification for range requests supports the possibility of multiple ranges.

[ajs6f]

There's also Guava Ranges.

[acoburn]

Because I've heard so many stories about Guava not being particularly backward compatible, I've been trying to avoid a dependency on it at the API or HTTP layer. However, I would have no hesitation about using it in any implementation code.

OTOH, if the API layer is only referencing the Guava types (and not actually doing anything with them), then maybe there is nothing to worry about. Though I'd still hesitate a little about pulling in all of Guava just to add a single type to an interface.

Thoughts?

[acoburn]

Perhaps Commons Lang3 Range would work. I have not been shy about requiring commons libraries.

[acoburn]

In fact, if we use o.a.commons.lang3.Range<T>, we can dispense with the VersionRange type in the Trellis API.

The core Trellis libraries don't currently depend on commons-lang3, but I'd prefer using that to Guava (at the API level).

[ajs6f]

I've heard the same qualms about Guava, but I have yet to hear of any very problematic concrete examples. Regardless, I've got nothing for Guava over Commons Lang. The strictly correct thing here would be to avoid exposing any of these prebuilt types and to make a Trellis-specific type for the purpose, but that's a pain in the butt.

[acoburn]

OK, for now I'll plan to use the Commons Lang types.