An updated package may not contain the same files that the old version did, so we need to remove those files. If we decide to create a new appId for the updated package (bug 1187156), this should be quite straightforward. We just evict everything in that appId's storage. Otherwise, for regular content, we need to do this before updating the package. So in PackagedAppChannelListener::OnStartRequest, we suspend the channel, doom existing cache entries for previous resources, and then resume the channel. (assuming OnStartRequest has a 200 OK status code).

(In reply to Valentin Gosu [:valentin] from comment #0) > An updated package may not contain the same files that the old version did, > so we need to remove those files. > > If we decide to create a new appId for the updated package (bug 1187156), > this should be quite straightforward. We just evict everything in that > appId's storage. > > Otherwise, for regular content, we need to do this before updating the > package. > So in PackagedAppChannelListener::OnStartRequest, we suspend the channel, > doom existing cache entries for previous resources, and then resume the > channel. (assuming OnStartRequest has a 200 OK status code). If we decide to create a new appId for the updated package, we shouldn't need to do anything specific since the old cache will automatically be expired and removed. (or we should explicitly call to evict them?) If we decide NOT to create new appId for updated package and need to remove the old version cache every time new version is detected, we might need to store meta data (at least a list of sub-resources) in somewhere other than the cache files. (could them be annotated to the package cache itself?)

Note that when you change (our internal) app's ID with every new version downloaded you actually wipe out also cookies, localStorage, indexedDB and any persisted data we distinguish by appid (between else) for that app. User will be frustrated. Are you ok with that?

(In reply to Honza Bambas (not reviewing) (:mayhemer) from comment #2) > Note that when you change (our internal) app's ID with every new version > downloaded you actually wipe out also cookies, localStorage, indexedDB and > any persisted data we distinguish by appid (between else) for that app. > User will be frustrated. Very good point. I had a talk with Jonas on Friday, and I think we're going to do the regular HTTP updating of cache entries (without changing appIds). Jonas will post some ideas into bug 1187156.

It might not be too hard to update the cookie/localstore/etc databases with the new appID. Just a SQL update statement, and I doubt it would be too slow given how infrequent an operation this is. Just an idea...

Added the dependency to Bug 1188717 which will store a list of cache files to the package's own cache (i.e. cache for 'package.pak')

Of course, we seem to be getting rid of appID-jars for all packages except those that use sensitive APIs, so this whole approach may be moot.

The web packaged apps implementation was removed from the tree.