Replies: 5 comments
-
Yea, the original intent (oh so long ago now) for this library was that it was an "all or nothing" type of operation. It simplifies things greatly. This is something that can be handled on the client using this library, but would require a full download again. Maybe first discuss what you think the API should look like. |
Beta Was this translation helpful? Give feedback.
-
The easiest part.
In can be few new method like:
in 2nd case
But with that approach we cannot handle multipart downloads for
Also we need to supply additional headers like current method
But... if RangeSpecification will be flexible enougth then we can leave only 3 methods:
Note:
dont know... Plus one more parameter increases overrided methods count. There is more ellegant solution with Builder pattern. But this will require a lot of work. Something like:
It will be good if every method will return new immutable object: i.e it should not modify current instance (and returns 'this') but instead it should returns new instance every time. In such case it will be thread safe and can do:
|
Beta Was this translation helpful? Give feedback.
-
just for example |
Beta Was this translation helpful? Give feedback.
-
Wow, excellent response. I like the builder idea, but yea, that is like a whole new version and a lot of work. Obviously, not my itch to scratch anymore. I haven't had a use for this project in probably 10 years. =( Crazy it is (and I am) this old! |
Beta Was this translation helpful? Give feedback.
-
Based on kool79's answer, I just did this to open a file starting at a specific position (to build a random input stream): HashMap<String, String> headers = new HashMap<>(); Worked like a charm! |
Beta Was this translation helpful? Give feedback.
-
Add native support for 'Range' header;
Add support for "If-Range" header
Add detection if server support partial file download.
Beta Was this translation helpful? Give feedback.
All reactions