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

Project status? #33

Closed
ChristianUlbrich opened this Issue Jun 19, 2014 · 30 comments

Comments

Projects
None yet
10 participants
@ChristianUlbrich

ChristianUlbrich commented Jun 19, 2014

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 comment has been minimized.

Show comment
Hide comment
@felixge

felixge Jun 19, 2014

Contributor

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.

Contributor

felixge commented Jun 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tim-kos

tim-kos Jun 19, 2014

Member

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 <
notifications@github.com> 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

Member

tim-kos commented Jun 19, 2014

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 <
notifications@github.com> 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

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Jun 20, 2014

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.

qsorix commented Jun 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@jf

jf Jun 20, 2014

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

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

jf commented Jun 20, 2014

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

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Jun 20, 2014

@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 .

qsorix commented Jun 20, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@jf

jf Jun 21, 2014

Thanks, @qsorix !

jf commented Jun 21, 2014

Thanks, @qsorix !

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Jun 22, 2014

Member

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.

Member

kvz commented Jun 22, 2014

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

This comment has been minimized.

Show comment
Hide comment
@ChristianUlbrich

ChristianUlbrich Jun 22, 2014

@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.

ChristianUlbrich commented Jun 22, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@vayam

vayam Jun 22, 2014

Member

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!

Member

vayam commented Jun 22, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tim-kos

tim-kos Jun 23, 2014

Member

@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.

Member

tim-kos commented Jun 23, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Jun 23, 2014

@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.

qsorix commented Jun 23, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@tim-kos

tim-kos Jun 24, 2014

Member

Hey @qsorix,

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

Member

tim-kos commented Jun 24, 2014

Hey @qsorix,

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

@ChristianUlbrich

This comment has been minimized.

Show comment
Hide comment
@ChristianUlbrich

ChristianUlbrich Jul 11, 2014

@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

ChristianUlbrich commented Jul 11, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@pmdarrow

pmdarrow Oct 2, 2014

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?

pmdarrow commented Oct 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Oct 3, 2014

Member

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?

Member

kvz commented Oct 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Oct 3, 2014

@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.

qsorix commented Oct 3, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@pmdarrow

pmdarrow Oct 3, 2014

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.

pmdarrow commented Oct 3, 2014

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

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Oct 8, 2014

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?

qsorix commented Oct 8, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Oct 10, 2014

Member

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.

Member

kvz commented Oct 10, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tim-kos

tim-kos Oct 10, 2014

Member

+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

Member

tim-kos commented Oct 10, 2014

+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

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Oct 10, 2014

@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. :)

qsorix commented Oct 10, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@tim-kos

tim-kos Oct 10, 2014

Member

Hey @qsorix

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

Member

tim-kos commented Oct 10, 2014

Hey @qsorix

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

@qsorix

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Oct 13, 2014

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

  • #14 - PUT vs PATCH
  • #2 - Range vs Content-Range
  • #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 commented Oct 13, 2014

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

  • #14 - PUT vs PATCH
  • #2 - Range vs Content-Range
  • #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

This comment has been minimized.

Show comment
Hide comment
@qsorix

qsorix Oct 27, 2014

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

qsorix commented Oct 27, 2014

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

This comment has been minimized.

Show comment
Hide comment
@tim-kos

tim-kos Nov 26, 2014

Member

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.

Member

tim-kos commented Nov 26, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Acconut

Acconut Dec 2, 2014

Member

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.

Member

Acconut commented Dec 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@michaelavila

michaelavila Dec 3, 2014

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

michaelavila commented Dec 3, 2014

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

@Acconut

This comment has been minimized.

Show comment
Hide comment
@Acconut

Acconut Dec 3, 2014

Member

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

Member

Acconut commented Dec 3, 2014

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

@Acconut

This comment has been minimized.

Show comment
Hide comment
@Acconut

Acconut Dec 10, 2014

Member

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

Member

Acconut commented Dec 10, 2014

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

@Acconut Acconut added the question label Dec 14, 2014

@kvz

This comment has been minimized.

Show comment
Hide comment
@kvz

kvz Sep 19, 2015

Member

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 #67
  • 1.0 Release #57
  • Developer Guide #59
  • Companies that (plan to) use tus tus/tus.io#28
Member

kvz commented Sep 19, 2015

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 #67
  • 1.0 Release #57
  • Developer Guide #59
  • Companies that (plan to) use tus tus/tus.io#28

@kvz kvz closed this Sep 19, 2015

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