Instead of installing, signed packages will have some kind of pinning mechanism where the user decides they want to "pin" the content. Liek bookmarking, but we will also pin the package to in the cache, so the content is persisted like an installed app.

As part of this bug we also need to take care of updating of pinned packages.

(In reply to Paul Theriault [:pauljt] from comment #1) > As part of this bug we also need to take care of updating of pinned packages. And also handle the case where the developer has removed the package altogether from the website. I wonder what we should do here? If the user has pinned the packaged, thats like an install, so maybe we should keep the old content, and assume the user wants to still use the content?

At the moment, web packaged apps are loaded into the cache under the system's principal, but I think each packaged app should have its own appId/principa. So when do we generate that appId? I assume it would be when we first load the package, so we can immediately put the cache entries into the right cache-jar. Any thoughts?

The way this will work is that we'll use a particular set appid/browserflag when fetching the package. When pinning, it should be pinned in the cache with that appid/browserflag. So only network loads that use that same appid/browserflag should receive that package. So at no point does necko need to transfer the package from one appid/browserflag to another. (On a separate note, we're working on converting code from explicitly using appid/browserflag to instead using the OriginAttributes struct. This struct is currently mainly a wrapper around appid/browserflag, but will let us add other forms of segmenting storage in a more generic way eventually.)

Is bug 1190290 the same as this one? Should we dupe either one to the other?

(In reply to Jonas Sicking (:sicking) from comment #5) > Is bug 1190290 the same as this one? Should we dupe either one to the other? Yes as far as I can tell. There is further discussion in the other bug, so i'm resolving this one.