Expose Durable Storage API to script

Source/modules/quota/StorageManager.idl

Index: Source/modules/quota/StorageManager.idl
diff --git a/Source/modules/quota/StorageManager.idl b/Source/modules/quota/StorageManager.idl
new file mode 100644
index 0000000000000000000000000000000000000000..31038b6f02e8ca1fc2b3de778fc5e1004e6f9f4e
--- /dev/null
+++ b/Source/modules/quota/StorageManager.idl
@@ -0,0 +1,15 @@
+// Copyright 2015 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.
+
+enum PersistentStoragePermission { "default", "denied", "granted" };
+
+[
+    Exposed=(Window,Worker),
+    TypeChecking=Interface,
+    GarbageCollected,
+    RuntimeEnabled=DurableStorage,
+] interface StorageManager {
+    [CallWith=ScriptState] Promise<PersistentStoragePermission> requestPersistent();
+    Promise<PersistentStoragePermission> persistentPermission();

[michaeln, 2015/06/19 23:24:50]

Is the worker part of that true? The strategy used in this blink cl and its
chromium sibling looks very 'window' oriented. What's the plan for the worker
part?

Did you take a look at how StorageQuota and queryStorageUsageAndQuota is put
together in blink and chromium renderer code? That strategy works for both
windows and workers. If these new durable perms interfaces really do need to
work in workers too, we might want to do something more along those lines.

[dgrogan, 2015/06/30 00:48:44]

The plan is that querying with persistentPermission will be exposed to workers
but requestPersistent() will only be exposed to window. I have a question out on
an IDL bug about how to best support this.
(https://code.google.com/p/chromium/issues/detail?id=503505#c2)
Yeah, definitely. I even had a few patches up
(https://codereview.chromium.org/1102353009/
https://codereview.chromium.org/1110063011/) that followed the old convention.
Could you give more detail about what you mean by "that strategy"?

+};