Project status?

[ChristianUlbrich]

We have adopted the semantics of the protocol in one of our applications. What is the current status of the project? Are there any plans on updating / enhancing the protocol (e.g. checksums)? It seems, that the development has somewhat stalled. If not, what is the best way to contribute to the project? Reporting/discussing in issues or PR or both?

[felixge]

This was my baby for most parts, but unfortunately I've left Transloadit, so I'm not really working on file uploads anymore. That being said, @kvz / @tim-kos would probably love to talk to you about possibilities for contributing.

[tim-kos]

Hey there,

would you be interested in a Skype call? My username is transloadit_tim.

Kind regards,
Tim

Co-Founder Transloadit
@tim_kos

On Thu, Jun 19, 2014 at 5:00 PM, Felix Geisendörfer <
[email protected]> wrote:

This was my baby for most parts, but unfortunately I've left Transloadit,
so I'm not really working on file uploads anymore. That being said, @kvz
https://github.com/kvz / @tim-kos https://github.com/tim-kos would
probably love to talk to you about possibilities for contributing.

—
Reply to this email directly or view it on GitHub
#33 (comment)
.

Practicing and Teaching the Art of Web Engineering

Tim Koschützki
Director
www.debuggable.com

Debuggable Limited
Friedrichstr. 171
Einstein Palais
10117 Berlin
Mob: +49 (151) 19161166

Commercial Register: HRB 112594 B (Charlottenburg, Berlin)
Directors: Tim Koschützki, Felix Geisendörfer
VAT-ID: DE263164617

[qsorix]

Just letting you know there are more people interested. Though I'm not sure I'll be able to devote significant amount of time to the development.

I've just started playing with this project, and if all goes well, I plan to use the protocol in our software. Checksums would be a valuable addition, as that's something we think we'll need.

[jf]

Yeah, I would be interested to find out (about the status of the project) too.

@qsorix : are tcp checksums not good enough for you?

[qsorix]

@jf: I share felixge's opinion: #7 (comment). Checksum is useful not only to catch transmission errors, but also bugs. Let's rather discuss checksums in #7 .

[jf]

Thanks, @qsorix !

[kvz]

Hi, Kevin from transloadit here. I see tus as the way forward in file uploads and although other pressing things have been on @tim-kos' and my plate recently - we will keep investing in this project. @vayam is the project lead these days and will have the final say when it comes to checksums. Personally I would +1 this.

@jf @qsorix besides checksums I'd be interested to hear about other things you think the protocol needs before we could reach a stable consensus, and/or you would consider it for adoption.

[ChristianUlbrich]

@tim-kos Do you happen to be at enterJS (http://www.enterjs.de) next week? If yes, we could discuss some things in person. If not, I will try to contact you in the 2nd week of July at the latest.

[vayam]

I have been using tus internally at vimeo. I agree there is need to add checksum and chunked uploads bunch of other features. I will start with all open issues and resume discussions. Feel free to ticket anything you want to see in the spec. Thanks!

[tim-kos]

@ChristianUlbrich Unfortunately I won't be there. @kvz and I will be on a Transloadit company trip and lock ourselves up for a couple days to work on something really cool. ;) We'll also dedicate some time to tus during the trip. This project is definitely not dead. :)

Looking forward to getting in touch with you second week of July.

@vayam I personally would also +1 checksums. Looking forward to your list of features.

[qsorix]

@kvz I will adopt tus, because it's the best thing I found so far. The solution is very simple and logical. Initially I intended to use google's API as used in Drive or Youtube, but then I found tus, which offers almost the same solution but aiming to use standardized methods.

Available implementations, especially production quality, are scarce and we may end up (especially client side) implementing it. Checksums will be required to avoid off-by-one errors in handling offsets etc. I'm more than willing to help you on that, because I don't want to become yet-another-small-company-with-custom-solutions.

What I miss most, and it's more urgent than checksums, is the version 1.0.0. I need to understand how to address upgrading the protocol in the future. Issue #29 seems to touch on this subject.

[tim-kos]

Hey @qsorix,

understood, and agreed - we need a 1.0.0. We'll work on that in the near future!

[ChristianUlbrich]

@tim-kos Sorry, have been busy this week. I try to publish my nodejs-based implementations on the week end. I will try to reach you next week. My skype handle is: christianulbrich

[pmdarrow]

I'd love to see this spec reach 1.0 as I really need to implement some of the suggested features. What's the latest on this project? @vayam have you made any progress on checksum and chunked uploads?

[kvz]

We (Transloadit) would like to see a 1.0 as well. Mainly because people seem to regard a < 1.0 protocol as unstable, which is hurting adoption. In my opinion though, the protocol well suited for implementation in production, even in its current v0.2.2 form.

To move the project forward I would like to propose the following:

We set a deadline for December 31st 2014. All the features that we can reach consensus on will be wrapped into the 1.0 release before that day.

The rest of the discussions will remain open, but as candidates for our 2.0 release.

Thoughts?

[qsorix]

@kvz, I agree that v0.2.2 is "good enought", we've implemented it already and it will be deployed soon. The only problem we had so far was a late realisation that we need to persist upload's meta-data for more time as otherwise our clients would have no way of identifying they've managed to upload the whole file.

Not having version "1.0" is not the main show stopper IMHO. It simply seem unfinished. There are many open features, some of which suggest that the key things are not decided yet (#33, #29, #26, #25, #14, #3).

The text of the protocol itself makes it clear that it is not finished. All those "This extension will define ..." seem like a long list of FIXMEs.

[pmdarrow]

I agree with @qsorix. Neither me nor my company are hung up on 1.0 as a version number, but there are a lot pieces unfinished which we can go ahead and implement ourselves but we're left with yet another non-standard implementation of resumable uploads. In particular we're interested in checksumming and parallel chunk uploads.

[qsorix]

We set a deadline for December 31st 2014. All the features that we can reach consensus on will be wrapped into the 1.0 release before that day.

@kvz, how do you imagine moving forward? Do you want go get more inputs in the open discussions? Do you feel what's there is enough and you guys just need to wrap your minds around all that once more and close them? How can the community help?

[kvz]

While we care less about 1.0 in itself, we care deeply about adoption and moving the project forward. Committing to a fixed release date might help to achieve this and avoid long quiet times. It's just my hope having seen it work well for other projects such as Ubuntu. I realize we are not Ubuntu : )

So it's up for discussion. Version, date, features that we slip in before it. I would personally love to reach consensus on checksums & retries before implementing tus in Transloadit for instance.

But this is a team effort and as authors of 1.0 I'd like us all to, not only chime in, but have the final say. We might need a better tool for reaching consensus than GitHub issue comments.

Short having/wanting dictators in our club, how about trying democracy via a voting system?
First we'd vote on open issues (deadlines? checksums? chunked uploads?) in order to prioritize them.
Then we'd go over the top issues, work out the different proposals for dealing with them, and vote on those.
Contributors & Collaborators would get to vote.

If you guys +1 this idea, I would love to hear your thoughts about simple voting systems that we could use to move the needle on these issues.

[tim-kos]

+1

Well we could try to stay on GH issues for simplicity for now, then create one issue that contains the roadmap for 1.0 and all the features that go into it. Everybody makes his/her votes like this:

+1 on feature 1
-1 on feature 2

These are just general features. There is a 1 - 2 week deadline for everybody to cast their vote.

After that every feature that made it on the roadmap gets its own Issue. We list out all the possible ways (if possible) of implementing it in the ticket description and then people vote on which way to take. There is a 1 - 2 week deadline again.

Then we find volunteers to implement specific features into the spec and also into some of the implementations like tusd.

We at Transloadit have completed a big milestone and our next big project is to port resumable file uploads back into the service. This means we hope to be much more involved here once again.

Best,
Tim

[qsorix]

@tim-kos, @kvz,

I don't believe in democracy when it comes to software design. In my opinion an average contributor may not have the required in-depth understanding of the whole project to make proper decisions. When design decisions need to be resolved by voting, it means we miss some information. It should be obvious why things need to be done in a certain way.

Personally, while I have my opinion on several of open issues and I'm able to vote for myself, I'm also aware that I haven't read as many RFCs as you guys, and I trust you more.

So in software, I prefer dictatorship. However, since you guys are my dictators here, and you say to vote... then let's vote! ;-)

I agree to voting on the priorities of issues/features that need to be done, because votes will reflect the actual demand for features. But when it comes to the way features are to be done, voting should be used only as an input in discussions, and dictators should make final decisions, even if it is against the votes. For the sake of consistency and simplicity of the protocol... or whatever your primary goals are. :)

[tim-kos]

Hey @qsorix

alright, that's a fair opinion that makes sense. Let's see what the others think. : )

[qsorix]

My list (votes) for issues that need to be done in milestone v1.0 is:

• PATCH vs PUT #14 - PUT vs PATCH
• "Range" vs. "Content-Range" #2 - Range vs Content-Range
• Allow protocol discovery between client and server. #29 - Protocol discovery

I believe that thanks to #29, future upgrades of protocol will be managable, so all other issues can be addressed in further revisions. #14 and #2 discuss core "shape" of the protocol and I think have to be closed to confidently say that TUS is 1.0-ready.

[qsorix]

Two weeks passed. :-) Time to get a roadmap for 1.0. I would suggest creating a v1.0 milestone and assigning issues there.

[tim-kos]

I think I agree about these thee issues. We need something that works today. No decision will be set in stone for forever and we might need to make changes again for 2.0 of the protocol.

But I agree that for version 1.0 of the protocol, getting just these three issues done will be a very good compromise.

[Acconut]

Just wanting to introduce myself. I will work from now on in Transloadit's name to push tus towards 1.0 and later 2.0.
As @qsorix said we first have to get a roadmap (see 1.0 milestone) which are mostly changes breaking backwards compatibility.
I'm looking forward to hear feedback.

[michaelavila]

Hey, just wanted to drop in on this thread and mention that all of this activity on this project is great to see!

[Acconut]

Thanks. I also enjoy that some of the original contributors are still interested although there was this big pause.

[Acconut]

@qsorix Both, #2 and #14 have already been implemented (see my comments).
So we should focus on the extensions more.

[kvz]

Working on a blog post with Project Status that we'll publish soon.
Closing this. Please use these other issues to further collaborate on tus 1.0. E.g.:

• More 1.0 implementations More 1.0 implementations #67
• 1.0 Release 1.0 Release #57
• Developer Guide Developer Guide #59
• Companies that (plan to) use tus Companies that (plan to) use tus tus.io#28