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. |
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: |
|
just for example |
|
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! |
|
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! |
Uh oh!
There was an error while loading. Please reload this page.
Add native support for 'Range' header;
Add support for "If-Range" header
Add detection if server support partial file download.
All reactions