Take 'http://people.mozilla.org/~fdesre/packages/loqui.pak!//index.html' as example. We might need some meta data stored in the cache of http://people.mozilla.org/~fdesre/packages/loqui.pak such as the package header, the list of all resources for further use. For example, when we find update available and are going to remove the old cache files, we need a list of cached resources to know what to remove.

Hi Valentin, I just attached a WIP for this bug. The basic idea is 1) Create nsIPackagedAppCacheInfo and let nsHttpChannel implement it. 2) At PackagedAppService::PackageAppChannelListener::OnStopRequest, to use the API I create in (1) to set the 'pkg-resources' meta data, which is ';'-separated URI list. Do you have any comment to this design? The patch compiles but fails to write the meta data to the package cache (the one which only has meta data but no content). I wonder if |OnStopRequest| is way too late to write meta data (although the expiration time may be updated at the same timing). I will be digging deeper tmr but do you find any apparent issue (most likely the misuse of cache APIs, I guess) in my patch? Thanks!

(In reply to Henry Chang [:henry] from comment #2) > Hi Valentin, > > I just attached a WIP for this bug. The basic idea is > > 1) Create nsIPackagedAppCacheInfo and let nsHttpChannel implement it. > 2) At PackagedAppService::PackageAppChannelListener::OnStopRequest, to use > the > API I create in (1) to set the 'pkg-resources' meta data, which is > ';'-separated > URI list. > > Do you have any comment to this design? > > The patch compiles but fails to write the meta data to the package cache > (the one which only has meta data but no content). I wonder if > |OnStopRequest| > is way too late to write meta data (although the expiration time may be > updated at the same timing). I will be digging deeper tmr but do you find > any > apparent issue (most likely the misuse of cache APIs, I guess) in my patch? I don't think you can change metadata at that point. From what I understand from Honza (bug 1036275 comment 92) you can only change metadata before opening the output stream for the cache entry, so it would not be possible OnStopRequest. Honza, can you think of another way of doing this?

You can change the metadata at any time. It only fails if the key+value is a too long string (ask Michal on limits) or we fail to allocate memory for it. You must count with failures, the code is not infallible. The reason to "only change metadata before opening the output stream" is to have a synchronization on metadata access for other waiting consumers on the same cache entry. If there are more consumers on a new cache entry (say two for simplicity) the first one is responsible to download the content (and headers) from the server. The second one is waiting. We wake the second cache listener by one of opening the output stream or calling MetaDataValid() on the cache entry. After that the second listener gets the entry and can read/write metadata and data freely. Usually it just reads. And when the first listener (the cache entry writer) writes all important metadata to the entry before opening the output stream/calling MetaDataValid() others gets the entry's metadata in a fully populated state.

BTW, if you want to store something bigger, we could use the content of the package app entry, just write to the entry's stream. For any parsing of that data please use mozilla::Tokenizer.

(In reply to Honza Bambas (not reviewing) (:mayhemer) from comment #5) > BTW, if you want to store something bigger, we could use the content of the > package app entry, just write to the entry's stream. > > For any parsing of that data please use mozilla::Tokenizer. Really thanks Honza! It seems the cache meta data is not appropriate to store the list of subresource. I'll probably store the list to the content in package app content and store the 'isSigned' attribute in each subresource's meta data. Thanks :)

The word "necessary info" is too general. The related works have been addressed in other bugs so mark this bug resolved.