Persist sessionStorage on disk.

webkit/dom_storage/session_storage_database.h

Index: webkit/dom_storage/session_storage_database.h
diff --git a/webkit/dom_storage/session_storage_database.h b/webkit/dom_storage/session_storage_database.h
new file mode 100644
index 0000000000000000000000000000000000000000..c2c801999305a3bab08cbfb337fa705ddf9ec63d
--- /dev/null
+++ b/webkit/dom_storage/session_storage_database.h
@@ -0,0 +1,53 @@
+// 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 WEBKIT_DOM_STORAGE_SESSION_STORAGE_DATABASE_H_
+#define WEBKIT_DOM_STORAGE_SESSION_STORAGE_DATABASE_H_
+#pragma once
+
+#include "webkit/dom_storage/dom_storage_database.h"
+
+namespace leveldb {
+  struct DB;
+}
+
+namespace dom_storage {
+
+// All DomStorageAreas for session storage share the same
+// SessionStorageDatabase.
+class SessionStorageDatabase : public DomStorageDatabase {
+ public:
+  explicit SessionStorageDatabase(const FilePath& file_path);
+  virtual ~SessionStorageDatabase();
+
+  // Reads all the key, value pairs stored in the database and returns
+  // them. |result| is assumed to be empty and any duplicate keys will
+  // be overwritten. If the database exists on disk then it will be
+  // opened. If it does not exist then it will not be created and
+  // |result| will be unmodified.
+  virtual void ReadAllValues(int64 namespace_id,

[michaeln, 2012/04/03 22:56:45]

This pre-existing interface borrowed from localstorage isn't expressive enough
to handle shallowclone / deepcopy type of semantics we're talking about for
sessionstorage. 

Rather than be constrained by that pre-existing interface, can you take a stab
at authoring a storage interface for sessionstorage specifically. I don't think
this class necessarily should derive from the same class currently used for
per-origin sqlite database files. We can come back later and reconcile how
'areas' talk to the storage interface, maybe some adapter classes that smooth
out the differences will come in handy at that time. 

[marja, 2012/04/10 15:34:45]

Yes, I added ShallowCopy() and DeepCopy() here. But it would be good to be able
to utilize the "db backing for in-memory data" logic of DomStorageArea, so that
I wouldn't need to rewrite that. DomStorageArea::ShallowCopy() and
Set|RemoveItem would then call these functions.

+                             const GURL& origin,
+                             ValuesMap* result) OVERRIDE;
+
+  // Updates the backing database. Will remove all keys before updating
+  // the database if |clear_all_first| is set. Then all entries in
+  // |changes| will be examined - keys mapped to a null NullableString16
+  // will be removed and all others will be inserted/updated as appropriate.
+  virtual bool CommitChanges(int64 namespace_id,
+                             const GURL& origin,
+                             bool clear_all_first,
+                             const ValuesMap& changes) OVERRIDE;
+ private:
+  virtual bool LazyOpen(bool create_if_needed);
+  virtual bool IsOpen() const;
+
+  // Helper for reading all values belonging to the map |map_id| into |result|.
+  void ReadAllValuesInMap(const std::string map_id, ValuesMap* result);
+
+  scoped_ptr<leveldb::DB> db_;
+};
+
+}  // namespace dom_storage
+
+#endif  // WEBKIT_DOM_STORAGE_SESSION_STORAGE_DATABASE_H_