Hello everyone.
Today I would like to ask community to give a right path for Meteor-Files 2.0. Any feature requests, suggestion and ideas is highly appreciated.
Lately this lib gained an attention, thank you to everyone who has a chance to use is. Lots of contributors have made this lib much better.
Now it's time for v2.0, time to move from CoffeeScript to ES6, time to remove all obsolete code.
Here is some of my thoughts and questions to you:
- As HTTP upload shows itself as faster, stable and more efficient than DDP (WebSockets), should we drop support for DDP? And put more focus on efficient and asynchronous uploads via HTTP? I've been playing with uploads directly from Web Workers - no more UI freezes, 1.5x speed increase, POST uploads from 3rd parties. To find out more about upload transports take a look on this article.
- Drop dependency from MongoDB. A lot of questions and issues about meta data, additional fields, etc. - This looks like bottleneck, which ties developers hands, and forces to rely on MongoDB, and to create records in strict schema. How about to put all control in hands of developer, and let you to decide where you should store file and how to describe its metadata? On Client you call
upload method, and on Server you receive everything you need at afterUpload hook. This one may also help to move this lib to NPM. Another good option is to split this lib into two - one which manages files as collections, and another which handles uploads.
- Protected files and uploads are also popular topic here. Need to standardise authentication method. Looking forward old friend
Authorization header with current Meteor token for uploads. For file requests (download, display, play) it's still unclear. As discussed here we can not rely on cookies as they are not accessible at various circumstances, especially on production with mobile apps. Authentication headers is not under control when you displaying file in HTML. Get query is not safe, HTTPS (SSL) partly solves get query parameters security.
- Is any of developers uses
public files? Like when it served by proxy-server nginx, apache, etc.
- What API do you prefer/most use?:
- Callbacks
- Events
- Promises
- Other?
As always main idea to keep this project flexible as possible, by providing thin API to work with files and uploads without overhead.
Hello everyone.
Today I would like to ask community to give a right path for Meteor-Files 2.0. Any feature requests, suggestion and ideas is highly appreciated.
Lately this lib gained an attention, thank you to everyone who has a chance to use is. Lots of contributors have made this lib much better.
Now it's time for v2.0, time to move from CoffeeScript to ES6, time to remove all obsolete code.
Here is some of my thoughts and questions to you:
uploadmethod, and on Server you receive everything you need atafterUploadhook. This one may also help to move this lib to NPM. Another good option is to split this lib into two - one which manages files as collections, and another which handles uploads.Authorizationheader with current Meteor token for uploads. For file requests (download, display, play) it's still unclear. As discussed here we can not rely on cookies as they are not accessible at various circumstances, especially on production with mobile apps. Authentication headers is not under control when you displaying file in HTML. Get query is not safe, HTTPS (SSL) partly solves get query parameters security.publicfiles? Like when it served by proxy-server nginx, apache, etc.As always main idea to keep this project flexible as possible, by providing thin API to work with files and uploads without overhead.