Proposed roadmap

[ramezrafla]

@NitroBAY , this is a list of the things we need to add for this repo to be production-ready and have wider adoption by the community. You don't have to implement them, just documenting

1. Make into a package
2. Use the settings passing approach of upup.js
3. Whitelist which domains / sites we can cache from (right now it caches everything) -- add ROOT_URL by default
4. Pass URL's to clear from cache say from one version of the app to the next

[I am sure I and others will think of more] Well done! This repo is great!

[ramezrafla]

5. Explain in Readme basic NGinx configurations for caching

[ramezrafla]

6. Add setting to pre-download assets, for apps that have strong offline capability
7. Should we keep history of when each asset is downloaded? For instance, when an app goes through an update we can send a command to delete all assets before a certain date so we are sure we are 'clean'
8. Browser quota management? If going overboard, start deleting older cached items (expose this as a setting)

[stephane-r]

Explain in Readme basic NGinx configurations for caching

This can be interesting indeed :)

[ilan-schemoul]

1. Make into package : as I explained I always wanted to do that but Meteor's team don't want to accept Mitar's pull request (https://github.com/meteor/meteor/issues/6222). His implementation could have been a reasonable way to implement workers in Meteor.
2. See the end of my text.
3. Yes, we may add this.
4. Hmm very interesting idea. Instead of using the heavy API to communicate with the API, I may define an URL which triggers the SW to clear the cache.
5. Yes.
6. Yes.
7. Same as 4 ? In any way yes.
8. Yes.

I didn't know upup, and the fact of having a constructor to register the SW is a great way to make the package more friendly. Globally there is a lot of possibility to do about this SW and a lot of them would require me to register a package. Tough I don't think I'm not going to make a package AND asking to put manually a file in /public. So when I first started all this I had much exciting ideas just like you BUT Meteor is actually missing the huge and great opportunity of web and service workers. It's a pity because not adopting new technologies surely cause great tools to stop being adopted by the community. One may want to show the support to Mitar's PR to include workers in Meteor's workflow. One of Meteor's team clearly said that they're gonna include workers only if the community really want them and show a lot of support about it. No it's all up to how many interesting people are gonna show about SW to Meteor's team. I created a project named "todo"

[ramezrafla]

@NitroBAY thanks for the comments. Do you want to add us as a collaborator to this repo or should we fork it? Thanks

[ilan-schemoul]

I prefer that you fork and make PRs to add a layer of security.

[ilan-schemoul]

What I've done : I started implementing a plugin system, a whitelist/blacklist system for my own app \ I.e : to handle responsive images, if I'm offline and the browser requests img.jpg?width=700 then let's returns the img.jpg?width=400, if the cache has already img.jpg?width=900 let's not cache img.jpg?width=100 etc.

But I would like a constructor, an API etc. to expose complex mechanisms (plugin system) and parameters (whitelist) etc. So I'm not going to update the app and ask devs to modify variables to use the different possibilities our Service Worker is going to offer. So I'm basically waiting Meteor to let us register a Service Worker to make this a package (as I said you can fasten the process by upvoting Mitar's proposal) and upvoting https://github.com/meteor/meteor/issues/5982). I'm going to close this issue as the todo list is now here but basically we cannot do anything if Meteor's team doesn't allow us to register Service Workers (they add the tag "feature" and "confirmed" since about 1 year). Thanks a lot for your precious advice and your interest @ramezrafla (I would be glad if you decide to keep collaborating with me).