search

tus / tus-java-client

The tus client for Java.
https://tus.io
MIT License
213 stars 88 forks source link

Client does not support "Upload-Defer-Length" if binary upload size is unknown #13

Closed rfelgent closed 7 years ago

rfelgent commented 7 years ago

Hello folks,

as far as I understand the client code, it does not support the "Upload-Defer-Length" which is required according to the "1.0.0" protocol version.

I am also wondering who to support this feature, as the current implementation uses a primitive long data type instead of a Long object. Therefore a "null" check is not possible. 

public class TusUpload {
    private long size;
...

Greetings

rfelgent commented 7 years ago

mmmhh.... is my problem not clear or is it just not that important to fix it?

I think, the "Upload-Defer-Length" feature must be correctly addressed by the official java implementation...

Acconut commented 7 years ago

mmmhh.... is my problem not clear or is it just not that important to fix it?

The time I available for the tus project is currently very limited due to private reasons. I would appreciate it enormously if you could understand that.

it does not support the "Upload-Defer-Length" which is required according to the "1.0.0" protocol version.

That is not entirely true. The functionality for deferring an upload's length is not a required feature for being compatible with the specification:

If the Server supports deferring length, it MUST add creation-defer-length to the Tus-Extension header.

This does not only apply to the Server but also the Clients, meaning that a client does not necessarily have to implement this feature. However, I agree with you, that it's nice to have and very useful in certain situation but we never can across one where we needed it in the tus-java-client. Therefore it's not available, yet.

I am also wondering who to support this feature, as the current implementation uses a primitive long data type instead of a Long object. Therefore a "null" check is not possible.

I don't think that this is a good design approach. Rather than having an attribute silently set to null (which could cause other subtle issues), I would prefer having an additional attribute (e.g. uploadLengthDeferred) which is more explicit and expressive.

If you are interested in helping in that regard, I am more than happy to assist you.

rfelgent commented 7 years ago

Hi @Acconut ,

mmmhh.... is my problem not clear or is it just not that important to fix it?

The time I available for the tus project is currently very limited due to private reasons. I would appreciate it enormously if you could understand that.

Sorry, It was not my intention to be impolite or attack anybody!

it does not support the "Upload-Defer-Length" which is required according to the "1.0.0" protocol version.

That is not entirely true. The functionality for deferring an upload's length is not a required feature for being compatible with the specification:

Ah, my mistake. I thought the official tus-java-client is a complete implementation of the TUS spec 1.0. That's why I was talking about a requirement/must have feature!

If you are interested in helping in that regard, I am more than happy to assist you.

Yes, I would like to create a pull request. I am very interested in a Java client which is a complete implementation of TUS 1.0 protocol, as I use it for my compatibility tests of my server side implementation of TUS 1.0 protocol (see: /rfelgent/sb-tus)

rfelgent commented 7 years ago

Hello @Acconut ,

pull request created with #15

Acconut commented 7 years ago

Nice work, thank you. Let's continue the discussion in #15.