service worker scaffolding

content/browser/service_worker/service_worker_context_core.h

Index: content/browser/service_worker/service_worker_context_core.h
diff --git a/content/browser/service_worker/service_worker_context_core.h b/content/browser/service_worker/service_worker_context_core.h
new file mode 100644
index 0000000000000000000000000000000000000000..9ce21daa980eb96005a165010ad09216f5154962
--- /dev/null
+++ b/content/browser/service_worker/service_worker_context_core.h
@@ -0,0 +1,40 @@
+// Copyright 2013 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_BROWSER_SERVICE_WORKER_SERVICE_WORKER_CONTEXT_CORE_H_
+#define CONTENT_BROWSER_SERVICE_WORKER_SERVICE_WORKER_CONTEXT_CORE_H_
+
+#include "base/files/file_path.h"
+#include "base/memory/weak_ptr.h"
+
+namespace base {
+class FilePath;
+}
+
+namespace quota {
+class QuotaManagerProxy;
+}
+
+namespace content {
+
+// This class manages data associated with service workers.
+// The class is single threaded and should only be used on the IO thread.
+// In chromium, there is one instance per storagepartition. This class
+// is the root of the containment hierarchy for service worker data
+// associated with a particular partition.
+class ServiceWorkerContextCore
+    : public base::SupportsWeakPtr<ServiceWorkerContextCore> {

[kinuko, 2013/11/07 03:02:59]

We're intermittently having 'kill SupportsWeakPtr' threads on chromium-dev.  I
think our usecase is fine, but maybe better note a comment about why we're using
this and this weakptr's visibility is basically 'private' within the service
worker lib? 

[michaeln, 2013/11/07 23:24:53]

Was just reading thru one of those threads. I'm picking WeakPtrs (and
SupportsWeakPtr specificically) as the least of the evil options available for
some defensive programming. I'm choosing to make this central class
SupportsWeakPtrs to defend against very unexpected behavior that can happen up
in higher level chrome/content code. In spirit, the central class *should*
outlive everything, but in practice user profiles can get deleted prior to
related child processes and ipc channels having been terminated/cleaned up.
Pathological cases turn up.

We'll have to code defensively to test if context_ prior to handling ipc
messages. It might be nice to put that test in the method containing the message
map? I'll look into that.

[kinuko, 2013/11/08 02:08:02]

We can also take destruction observer pattern or propagate Shutdown down to
child classes (though these patterns also have their own downside). I'm
wondering if we'll have cases where child classes want to know the timing the
context goes away and make some actions (e.g. prepare for shutting down).
Thoughts?
Sounds good.

[michaeln, 2013/11/09 00:24:00]

If we ever have the need to observe destruction and take action at that time, we
can write code to do that. I don't anticipate we'll need that.

+ public:
+  ServiceWorkerContextCore(const base::FilePath& user_data_directory,
+                           quota::QuotaManagerProxy* quota_manager_proxy);
+  ~ServiceWorkerContextCore();
+
+ private:
+  scoped_refptr<quota::QuotaManagerProxy> quota_manager_proxy_;
+  base::FilePath path_;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_SERVICE_WORKER_SERVICE_WORKER_CONTEXT_CORE_H_