Persist sessionStorage on disk.

content/public/browser/dom_storage_context.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_PUBLIC_BROWSER_DOM_STORAGE_CONTEXT_H_
 #define CONTENT_PUBLIC_BROWSER_DOM_STORAGE_CONTEXT_H_
 
 #include <vector>
 
 #include "base/callback.h"
@@ skipping 13 matching lines @@
   typedef base::Callback<
       void(const std::vector<dom_storage::DomStorageContext::UsageInfo>&)>
           GetUsageInfoCallback;
 
   // Returns a collection of origins using local storage to the given callback.
   virtual void GetUsageInfo(const GetUsageInfoCallback& callback) = 0;
 
   // Deletes the local storage data for the given origin.
   virtual void DeleteOrigin(const GURL& origin) = 0;
 
+  // If this is called, sessionStorage data will be stored on disk, and can be
+  // restored after a browser restart (with RecreateSessionStorage). This
+  // function must be called right after DOMStorageContextImpl is created, and
+  // before it's used.
+  virtual void SetSaveSessionStorageOnDisk() = 0;

[michaeln, 2012/07/12 21:09:15]

This works but its an awkward method with that must be called after creating and
before using and such. An alternative could be to hang a new method on either
ContentClient or ContentBrowserClient which can be overriden by chrome to return
true (and false by say ContentShell), and have DomStorageContextImpl.cc query
that interface during construction/initialzation. That would take it out of the
'profile' world (but we'd also loose the ability to toggle this on/off
per-profile).

[marja, 2012/07/13 09:05:17]

Yes, okay, that would work. I can do that in a separate CL if we agree that
that's the right way to do this. jam, wdyt?

[jam, 2012/07/13 17:42:56]

ContentBrowserClient is a last-resort interface, where there's no context and so
content calls the embedder's "static" interface.

Given that the embedder is the one that creates the BrowserContext, I don't
think there's an issue if they have to set advanced flags on it that almost no
other embedder of content will care about. This keeps the interfaces that every
embedder has to implement simpler (i.e. ContentBrowserClient or BrowserContext).

+
   // Creates a SessionStorageNamespace with the given |persistent_id|. Used
   // after tabs are restored by session restore. When created, the
   // SessionStorageNamespace with the correct |persistent_id| will be
   // associated with the persisted sessionStorage data.
   virtual scoped_refptr<SessionStorageNamespace> RecreateSessionStorage(
       const std::string& persistent_id) = 0;
 
+  // Starts deleting sessionStorages which don't have an associated
+  // SessionStorageNamespace alive. Called when SessionStorageNamespaces have
+  // been created after a session restore, or a session restore won't happen.
+  virtual void StartScavengingUnusedSessionStorage() = 0;
+
  protected:
   virtual ~DOMStorageContext() {}
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_BROWSER_DOM_STORAGE_CONTEXT_H_