[Do not merge] Idea: Support different client implementations

[yciabaud]

I was looking for a meteor server implementation for flowjs (fork of resumable) and I found your package.

So I decided to remove all resumable client implementation and add the support for flowjs properties in the server side and I ended with a server only package compatible with both resumable and flowjs clients.

I am posting my changes here to discuss to possibility to make your package compatible with flowjs either by splitting it in server and client packages or some better way you can think about.

Any thoughts?

[vsivsi]

It's an interesting idea for sure. I'm also interested in supporting the emerging tus upload protocol as well.

I did some work awhile back to make things a lot more pluggable. So now, the server-side resumable.js support is almost completely self-contained, and uses the same hooks as user-provided HTTP routes to integrate itself.

But I didn't separate it entirely because probably 50% of the devs coming to this package are fairly new to this stuff and having a turnkey / low friction / "just works" default setup for upload has been extremely valuable. As soon as you start splitting things out into too many sub-packages with weird dependencies and other interactions the whole thing can quickly become un-fun to work with (witness CollectionFS, which is no longer supported...)

Also, Am I correct in assuming that you wanted the flowjs/resumablejs backend, but not necessarily the dependency on gridFS for storage? That for me is the red-line for this package, it's a MongoDB/gridFS file management package for Meteor. That's it. If you want S3 buckets or native filesystem support, the answer is CollectionFS (or something else new).

Anyway, I'm willing to discuss, but will have very limited time in the next few months for actual implementation. I'll take a look at what you've done here over the weekend and make some more specific comments / suggestions once I've done that.

Thanks!

[yciabaud]

I understand your point and the consequences of splitting a package. I forked your project and wanted to have your opinion on this.

To answer your question, I want to use gridFS , I was using S3 with evaporateJS previously but now I need to process the files locally before storing it and I am looking for a robust solution to manage my uploads.

My changes on the request parameters are pretty straightforward, but I did not wanted to have the resumable dependency on the client so I removed it.

Maybe you can make your package compatible with other clients without removing resumable dependency.