Framing for a DOMStorage backend that does not depend on in-process-webkit.

webkit/dom_storage/dom_storage_task_runner.h

Index: webkit/dom_storage/dom_storage_task_runner.h
===================================================================
--- webkit/dom_storage/dom_storage_task_runner.h	(revision 0)
+++ webkit/dom_storage/dom_storage_task_runner.h	(revision 0)
@@ -0,0 +1,54 @@
+// 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_DOM_STORAGE_TASK_RUNNER_
+#define WEBKIT_DOM_STORAGE_DOM_STORAGE_TASK_RUNNER_
+#pragma once
+
+#include "base/memory/ref_counted.h"
+#include "base/threading/sequenced_worker_pool.h"
+
+namespace base {
+class MessageLoopProxy;
+}
+
+namespace dom_storage {
+
+// Tasks are guaranteed to run serially with respect to
+// one another, but may execute on different OS threads.
+// They're executed via the SequenceWorkerPool under a
+// dom_storage specific SequenceToken.
+class DomStorageTaskRunner

[benm (inactive), 2012/02/02 16:23:19]

This change is getting a bit big IMHO with a mix of skeleton files and real
impl... this class feels like it could go into it's own patch (nice and self
contained)? It'd be nice to keep this patch as just skeletons, I think.

[michaeln, 2012/02/03 00:33:42]

It's actually not so skeletal anymore. There are no bindings to read/write from
disk, and it doesn't track/enforce quota limits, but otherwise i think these
classes should function. I'd rather not strip the method bodies out an land just
.h file.

Not sure where to draw what lines for landing things?

The TaskRunner is an outlyer and for testing purposes it should would be nice to
have an impl that really just posts everything to the MessageLoop of the current
thread. Maybe i can make that more of an abstract class and commit a 'mock' impl
that does just that as one CL, and come back later with an impl that uses
SequencedWorkerPool.

Area and Map overlap with some of your work thus far, so it'd be good to get
those in asap so you can start binding things the Database class.

So how's this for a commit sequence...
1) abstract taskrunner + mock that uses MessageLoop only
2) Map + unittests
3) Area + unittests

Since area depends on namespace.h for kLocalStorageNamespaceId, and we collide
on the definition of ValueMap, i'll make a dom_storage_types.h file for those
definitions and put it in CL 2. You say you've already got Area/Map 'ish
unittests in the works, maybe I can commit w/o tests and we can back fill?

4) Host/Context/Namespace + unittests
5) TaskRunner backed by sequenced worker

Your db change can go in anytime prior to the Area + DB integration.

+    : public base::RefCountedThreadSafe<DomStorageTaskRunner> {
+ public:
+  DomStorageTaskRunner(
+      base::SequencedWorkerPool* sequenced_worker_pool,
+      base::MessageLoopProxy* delayed_task_loop);
+  ~DomStorageTaskRunner();
+
+  // Schedules a sequenced worker task to be run immediately.
+  void PostTask(
+      const tracked_objects::Location& from_here,
+      const base::Closure& task);
+
+  // Schedules a sequenced worker task to be run after a delay.
+  void PostDelayedTask(
+      const tracked_objects::Location& from_here,
+      const base::Closure& task,
+      base::TimeDelta delay);
+
+ private:
+  // Tasks are executed in sequence via the SequencedWorkerPool.
+  base::SequencedWorkerPool* sequenced_worker_pool_;  // not owned
+  base::SequencedWorkerPool::SequenceToken sequence_token_;
+
+  // Delayed tasks are scheduled on the worker pool only
+  // after the delay has passed. This seperate message
+  // loop provides the delay.
+  scoped_refptr<base::MessageLoopProxy> delayed_task_loop_;
+};
+
+}  // namespace dom_storage
+
+#endif  // WEBKIT_DOM_STORAGE_DOM_STORAGE_TASK_RUNNER_
Property changes on: webkit\dom_storage\dom_storage_task_runner.h
___________________________________________________________________
Added: svn:eol-style
   + LF