New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/tus #10

Merged
merged 5 commits into from Oct 21, 2015

Conversation

Projects
None yet
2 participants
@choonkeat
Owner

choonkeat commented Oct 20, 2015

Implements http://tus.io/ open protocol for resumable uploads support

cc @khangtoh

choonkeat added some commits Oct 20, 2015

Upload to cloud as-we-patch
slow but allows switching of servers between requests
Attache.cache.write to create file when current_offset errors - compatiblity fix for tus.js client
@choonkeat

This comment has been minimized.

Show comment
Hide comment
@choonkeat

choonkeat Oct 20, 2015

Owner

FYI @winston TUS upload protocol is more suitable for API integration, e.g. mobile app upload big file over flaky network

The only difference with TUS here is that the PATCH response comes with a JSON that the client app should read and store.

Owner

choonkeat commented Oct 20, 2015

FYI @winston TUS upload protocol is more suitable for API integration, e.g. mobile app upload big file over flaky network

The only difference with TUS here is that the PATCH response comes with a JSON that the client app should read and store.

@choonkeat choonkeat referenced this pull request Oct 20, 2015

Open

More 1.0 implementations #67

2 of 8 tasks complete
@choonkeat

This comment has been minimized.

Show comment
Hide comment
@choonkeat

choonkeat Oct 21, 2015

Owner

FYI @zamakkat @shinnyx for clients uploading over unreliable networks, can use the tus.io protocol (which will be 1.0 soonish) on /tus/files endpoint for resumable upload

Owner

choonkeat commented Oct 21, 2015

FYI @zamakkat @shinnyx for clients uploading over unreliable networks, can use the tus.io protocol (which will be 1.0 soonish) on /tus/files endpoint for resumable upload

choonkeat added a commit that referenced this pull request Oct 21, 2015

@choonkeat choonkeat merged commit 3be2c4e into master Oct 21, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@choonkeat choonkeat deleted the feature/tus branch Oct 21, 2015

@winston

This comment has been minimized.

Show comment
Hide comment
@winston

winston Oct 21, 2015

Just to clarify, basically we are implementing the TUS standard/protocol here (headers) right?

winston commented Oct 21, 2015

Just to clarify, basically we are implementing the TUS standard/protocol here (headers) right?

@choonkeat

This comment has been minimized.

Show comment
Hide comment
@choonkeat

choonkeat Oct 21, 2015

Owner

Yes, but

  • TUS protocol is only available at /tus/files end point; does not affect the regular /upload endpoint
  • according to protocol, the PATCH response is just HTTP 200 and Offset header (both of which we are doing). But on top of it, we're also returning the json body like what we do for regular attache file upload. This should be a compatible extension to the existing protocol, and I suspect/hope is something not difficult for a client to implement
Owner

choonkeat commented Oct 21, 2015

Yes, but

  • TUS protocol is only available at /tus/files end point; does not affect the regular /upload endpoint
  • according to protocol, the PATCH response is just HTTP 200 and Offset header (both of which we are doing). But on top of it, we're also returning the json body like what we do for regular attache file upload. This should be a compatible extension to the existing protocol, and I suspect/hope is something not difficult for a client to implement
@winston

This comment has been minimized.

Show comment
Hide comment
@winston

winston Oct 21, 2015

This should be a compatible extension to the existing protocol, and I suspect/hope is something not difficult for a client to implement

Ah yes. There's always the client side story to this too.. Keep forgetting that.

winston commented Oct 21, 2015

This should be a compatible extension to the existing protocol, and I suspect/hope is something not difficult for a client to implement

Ah yes. There's always the client side story to this too.. Keep forgetting that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment