@dr.dimitru Exactly! The API should have two methods upload and trash. It should give two hooks to validate usage of these two methods.
For simplicity I think you should continue using a MongoDB collection to publish what files are available and this collection could be freely updated by the user, to add metadata for instance (I don’t know what would be a reliable way of preventing the user from calling insert or remove on this collection, or breaking the database by updating library specific fields with update). If you do not do this, you still need to have a way to list what files are available for garbage collection purposes (for instance uploads that succeeded but that were never linked to anything in the user’s system).
Furthermore I suggest that supported 3rd party storage should have implementation (plugins?) rather than documentation only (if someone is willing to do maintenance). In an application I work on I use file storage for instances deployed on my own hardware because I don’t want to upload sensitive data to the cloud and I want to simplify backup/restore/migration procedures by storing everything in the database. Therefore I use GridFS and I find that having to write your own hooks for such a standard solution feels a bit shaky. I would be more confident using a plugin that occasionally gets updates from the community that are then automatically deployed on the next dependency upgrade. Low-level hooks (afterUpload, afterTrash) should remain to allow for unsupported storage solutions.
@aureooms well… what you’ve described sounds ideal, and I wish to do that.
Ideally that should be bare-bone “upload” library with bunch of plugins for each and every storage solution, as well as framework (Meteor in our case).
At the same time that would require a lot of maintenance from my end, which, well… equals time. At this moment I contribute and maintain open source packages used in commercial projects I care about. Open source itself gives me joy (like chatting with you guys here ), but it’s far away from full-time work, atm I contribute as much as I can, and will in the future.
I’ll build “light” version with plugins in mind, — with simple, but rich API + docs and tutorials.
I would really appreciate the package, and I like the idea of a small, stable interface that abstracts away that single, tricky problem.
The extensive documentation and examples you’re envisioning are icing on the cake – which is, of course, the best part of the cake. It makes it so that the package comes in two parts: the core part that gets imported, and the super flexible part that gets cut-paste-modify’d from the documentation according to the use case.
I was going to suggest Meteor-Upload for the name, but perhaps something less Meteor specific if you’re going to publish on npm. Still, I think shifting the focus from Files to Upload might be an idea.
Also: I’m just integrating with Meteor-Files in a project for the first time at the moment, and I’m grateful for the package. the documentation, and the examples.
@colinf I’m glad you are sharing the vision of lightweight bare-bone upload library.
And I’m glad you’ve found a use in Meteor-Files library
Do not hesitate to ask questions over Meteor-Files package via GitHub issue or forum mentioning me.
), but it’s far away from 
