My proposal is to put them in a LevelDB – x-platform and very Node-y.

Cool. If the caches can't be explored on disk it'd be great to have a url
to inspect them (future idea, of course).

Actually, since there's programmatic cache access, this could be written as
a separate project, built with a ServiceWorker.
On 9 Jan 2014 12:20, "Tom Ashworth" notifications@github.com wrote:

My proposal is to put them in a LevelDB – x-platform and very Node-y.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-31925613
.

So, more thinking about this:

• LevelDB is over-complicating it. All Responses are JSON stringifyable, so they should go in files
• This is also easier to debug
• Caches are grouped by domain, so I suggest using a file named by domain:

http-google-com.json
[
  {
    "name": "shell-v2",
    "items": {
      "some-url": { ... }
    }
  },
  { "name": "contents-v2", "items": { ... } },
  ...
]

• The Cache should return a Promise for writing to this file
• What does it mean to ask Cache#has? Only if definitely written.
• Cache order is important
• Maybe use promised-io

More thinking, new data structure schema:

/*

caches/
    origin/
        cache-xyz789.json
        bodies/
            body-123abc.json

*/

// cache-xyz789.json
{
    items: [{
        state: 'pending/fulfilled/rejected',
        request: { ... },
        resonse: {
            ... ,
            body: 'body-123abc'
        }
    }]
}

// body-123abc.json
{
    body: [123, 456, 789]
}


/*

cache-lists/
    some-origin.json

 */

// some-origin.json
{
    caches: [{
        name: 'app-cache',
        id: 'cache-xyz789'
    }]
}

For the sake of the polyfill, garbage collecting caches when the worker is shut down is fine

• persist all Caches to a cache heap
• bodies also go on heap
• when Cache is set to CacheList, point the CacheList to that cache