[Storage] Cache storage inspection on all the frames!

Source/devtools/protocol.json

Index: Source/devtools/protocol.json
diff --git a/Source/devtools/protocol.json b/Source/devtools/protocol.json
index 4863b3e55416d2bf69f58582a12d5b5f14233229..620bc12ae3336aac84909bd851b90f4ba75cdf5b 100644
--- a/Source/devtools/protocol.json
+++ b/Source/devtools/protocol.json
@@ -1681,7 +1681,7 @@
         ]
     },
     {
-        "domain": "ServiceWorkerCache",
+        "domain": "CacheStorage",
         "hidden": true,
         "types": [
             {
@@ -1698,6 +1698,9 @@
             {
                 "name": "requestCacheNames",
                 "async": true,
+                "parameters": [
+                    { "name": "securityOrigin", "type": "string", "description": "Security origin." }

[pfeldman, 2015/04/09 10:31:12]

Now sure why fetching by origin is important, lets fetch all.

+                ],
                 "returns": [
                     { "name": "cacheNames", "type": "array", "items": { "type": "string" }, "description": "Cache names for origin." }
                 ],
@@ -1707,6 +1710,7 @@
                 "name": "requestEntries",
                 "async": true,
                 "parameters": [
+                    { "name": "securityOrigin", "type": "string", "description": "Security origin." },

[pfeldman, 2015/04/03 09:15:58]

Composite ids is hard to work with for the clients, I'd rather expose cacheId
instead of a cache name + sequrity origin that would uniquely identify it. Even
at the expense of parseable composite "securityorigin:name" id at the backend
that is opaque to the front-end.

[dmurph, 2015/04/08 19:35:35]

Just to clarify, you want me to remove the securityOrigin and cacheName part and
instead use a cacheId string that would then be parsed in the backend?

Just FYI, IndexedDB does it this way.  Also, there are cases, like
requestCacheNames, where we only need the security origin.

Also, how is this hard to work with?

[pfeldman, 2015/04/09 10:31:12]

Yes.
Too bad for IndexedDB. Why would we need requestCacheNames per security origin?
Why composite primary key is bad? Well, because when working with the remote
instance, you need a handle to that instance that would identify it. You operate
on this instance using this handle to refer to it, you associate updates to the
instances based on that handle. So there is inevitably a lookup from the handle
to the instance and back. That's why clients of your API will be concatenating
the sequrityOrigin and cacheName in one string in order to flatten it and use a
single map for a lookup. Or even worse, will use hierarchical maps.

                     { "name": "cacheName", "type": "string", "description": "Cache name." },
                     { "name": "skipCount", "type": "integer", "description": "Number of records to skip." },
                     { "name": "pageSize", "type": "integer", "description": "Number of records to fetch." }
@@ -1721,6 +1725,7 @@
                 "name": "deleteCache",
                 "async": true,
                 "parameters": [
+                    { "name": "securityOrigin", "type": "string", "description": "Security origin." },
                     { "name": "cacheName", "type": "string", "description": "Cache name." }
                 ],
                 "description": "Deletes a cache."