Future of this library?

[binarykitchen]

Hello there

Is this really the official, next version of https://github.com/23/resumable.js ?

I realise it has some flaws and I wonder if I really should use yours instead. Which one is better maintained and will be?

Lemme know, thanks!

[AidasK]

Hi

First of all, we (I and Steffen) had a disagreement on further library development. It seems Steffen is not ready for big changes. Because of this i have created https://github.com/resumable2 organization.
So this library is a fork from the first version of resumable.js and i am hoping to make it better. It seems original author is not so enthusiastic about its development. It has unfinished features for 2 month now https://github.com/23/resumable.js/issues?direction=desc&labels=v2&page=1&sort=created&state=open.

Which one should you choose?
https://github.com/resumable2/resumable.js is 86% tested, it contains more features, all code is documentated, it size is only 12kb then minified (resumable.js v1 is also 12kb in size, duplicated code?). Also look at other libraries for resumable.js v2:
https://github.com/resumable2/maybe-resumable.js - ie7+ support,
https://github.com/resumable2/ng-resumable - angular extension,
https://github.com/resumable2/resumable.js-php-server - php library.

Which one is better maintained and will be?
Who knows, but for now i am using this library in production and i hope to make it even better.
Also all of these libraries are unfinished for now, but i hope with your collaboration we can make them well written, well tested and feature rich.

[binarykitchen]

Ouch, sorry about that @AidasK @steffentchr @resumable2 @danimt @Bantam

I think this discussion is too important to ignore, hence I mentioned you all. I've been looking for a library like this one for a long time. I see a huge potential here. Especially because the HTML5 File API is so new. I need it for a node.js driven video portal for videos up to 1 GB. I think there are none out there except yours.

So, what's up between you guys? Allow me to be blunt: put your cards on the table. Why don't you work together and make it an awesome library for the node.js community?

A couple of things from my part: My time is very limited, I am working 16 hours a day to a deadline, but am very happy to help whenever, wherever I can. And yes, forget IE7 support. To be honest, who cares these days?

Okay, looking forward to read all your comments ...

[steffentchr]

@binarykitchen + @AidasK @danimt @Bantam

It's an important discussion to some extent, but there's not too much drama here: Resumable.js grew out of a project we ran at @23 a few years ago -- and has been used in production to upload terabytes of video files since then. The scope of the project was to build a simple, HTML5-only JS lib that handled connectivity issues gracefully while supporting upload of large files. I wrote the code to match my preferences for code style and to include the features I needed to launch the 23 Video uploader. Over time, the library has been updated and bug-fixes by myself and through users contributions. This has grown the feature-set nicely.

Now, @AidasK was nice enough to provide a number of very valuable contributions over the summer, and most of these were merged into the repository. However, we parted way on two different issues: Breaking changes (especially the ones that would force server-side implementations to be updated in order for the library to work) and code style (I don't like Google's JS style guide, @AidasK does). For that reason, we talked about how to organise work of a v2 of Resumable.js.

What would my preference be for the future of Resumable.js?

• Merge in non-breaking changes to the current version of the library. Measurement of upload speed is a good example of that.
• Start a thread and a branch to decide what as Resumable.js v2 looks like. How would it balance simplicity with features? Which browsers would it support; would it attempt to support old, non-HTML5 browsers? Would it ship with full implementations and modules for certain server-side frameworks to make sure that we can move those as Resumable.js moves?
• Branch it, build it, merge it, ship it.

That was my suggestion in July, but instead there's now a competing Resumable2. Shit, I know it's pretty, but it does annoy me quite at bit to have someone else use "my" name to build a version of the library -- and taking it in a direction I don't necessarily agree with. And it does kinda annoy me, when I'm said not to be ready for big changes and to not be enthusiastic about development. Pretty, yes. But human.

Future? Well, I'd love to merge the energies and build a real v2. I'd love to involve the input of more that just @AidasK and myself. I'd love love not to be writing long essays about why I'm not giving peace a chance.

Will it happen? No clue...

[AidasK]

Okey, it is v2 right? Why not to break something? I think it is the best time for good changes.
https://github.com/resumable2/resumable.js now supports only HTML5 browsers and i think it should be so. For this reason i have created IE7 support library in a different repository. Don't use it if you don't want.

Why not to follow some style guide? https://github.com/23/resumable.js follows 23 project style guide and it looks odd to me. Most of us use this http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml. Is it bad to use most popular style guide for a library?

I also don't agree to merge library to https://github.com/23/resumable.js, because it is veary hard to maintain library throught pull requests. I think organisation is mandatory here. I can add All of you as a members. If you like, i can make Steffen as organisation owner, but you will have to be more open minded and more active.

[steffentchr]

Okey, it is v2 right? Why not to break something? I think it is the best time for good changes.
https://github.com/resumable2/resumable.js now supports only HTML5 browsers and i think it should be so. For this reason i have created IE7 support library in a different repository. Don't use it if you don't want.

Don't disagree with any of that. v2 is breaking. That's the reason to have v2. I like the approach of an optional backwards-compatibility.

Why not to follow some style guide? https://github.com/23/resumable.js follows 23 project style guide and it looks odd to me. Most of us use this http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml. Is it bad to use most popular style guide for a library?

Preferences are different. As in, this is an area where the only viable path is agreeing to disagree.

I also don't agree to merge library to https://github.com/23/resumable.js, because it is veary hard to maintain library throught pull requests. I think organisation is mandatory here.

These are not mutually exclusive. Teams and organizations can be given access to repositories. So nothing too problematic there.

So far, so good...

I can add All of you as a members. If you like, i can make Steffen as organisation owner, but you will have to be more open minded and more active.

These are a kinds of personal statements that make me think that collaboration is not a good idea. That might be horribly "close-minded", but it's also realistic.

Any way I could ask you to pick a different name for the fork?

[Bantam]

Willing to contribute to whatever plan you guys decide on! We have a few changes to contribute to a v2 that we can merge in. Style guides put barriers in the way to people contributing in my opinion. If you guys can't agree then fork should be named something else out of respect. After reading the commit log it seems like there are not many breaking changes so at this point changes could be merged back in.

[AidasK]

After reading the commit log it seems like there are not many breaking changes so at this point changes could be merged back in.

There are lots of features, bug fixes and tests. I don't think it is possible to transfer all of this to an old repository.

Shit, I know it's pretty, but it does annoy me quite at bit to have someone else use "my" name to build a version of the library -- and taking it in a direction I don't necessarily agree with.

@steffentchr Should i remove your name from the library? Should i leave it in the license?

The best option will be to rename this repository (Maybe OtterJs?), in this way library can be actively developed.

[steffentchr]

@AidasK Would love a mention in license and readme, although it's obviously not required by the license terms of Resumable.js. Something like, "this library originates from Resumable.js and expands the feature set and scope of that library".

About names, I'm happy just to not have it be Resumable2, but I'll leave the creativity in your hands. You could even be cheeky and play on your perception of action vs inaction by calling it Resumed.js ;-)

[AidasK]

I will think about mentioning resumable.js in a readme, because some issues are the same for both libraries.

I am still not decided about library naming, but i prefer OtterJs (It is like Bower, Grunt - nothing in common with a library, but easy to found and remember). Planning to rename it next week, waiting for your suggestions and thoughts.

[binarykitchen]

Cool, you guys talking. A different library name is definitely nice. The otter logo is cute.

And yes, if resumable.js did inspire you @AidasK then you should show come credits to @steffentchr I think. Not just out of respect, also because it feels right from a social perspective.

Anyway, happy coding! Time will tell which library will rule ...

[AidasK]

Library was renamed to flow.js

[binarykitchen]

Cool, I'll check out your changes soon.