Get rid of the half-working traces of locking, caching, and quotas. It

probably shoudln't have been added in to begin with.

BUG=none
TEST=none

Review URL: http://codereview.chromium.org/203015

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@25966 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 1 insertions, 13 deletions

diff --git a/webkit/api/public/WebStorageArea.h b/webkit/api/public/WebStorageArea.h
index 664b418..b67aea6 100644
--- a/webkit/api/public/WebStorageArea.h
+++ b/webkit/api/public/WebStorageArea.h
@@ -37,24 +37,12 @@ namespace WebKit {
     class WebString;
 
     // In WebCore, there's one distinct StorageArea per origin per StorageNamespace. This
-    // class wraps a StorageArea. With the possible exception of lock/unlock all of these
-    // methods map very obviously to the WebStorage (often called DOM Storage) spec.
+    // class wraps a StorageArea.  All the methods have obvious connections to the spec:
     // http://dev.w3.org/html5/webstorage/
     class WebStorageArea {
     public:
         virtual ~WebStorageArea() { }
 
-        // Lock the storage area. Before calling any other other methods on this interface,
-        // you should always call lock and wait for it to return. InvalidateCache tells you
-        // that since the last time you locked the cache, someone else has modified it.
-        // BytesLeftInQuota tells you how many bytes are currently unused in the quota.
-        // These are both optimizations and can be ignored if you'd like.
-        virtual void lock(bool& invalidateCache, size_t& bytesLeftInQuota) = 0;
-
-        // Unlock the storage area. You should call this at the end of the JavaScript context
-        // or when you're about to execute anything synchronous per the DOM Storage spec.
-        virtual void unlock() = 0;
-
         // The number of key/value pairs in the storage area.
         virtual unsigned length() = 0;