Initialize the simple cache backend at runtime.

net/disk_cache/disk_cache.h

Index: net/disk_cache/disk_cache.h
diff --git a/net/disk_cache/disk_cache.h b/net/disk_cache/disk_cache.h
index 13edd92f21620a31a1b44a1f155ed1f80bc59ab6..52d4a41689a1f3855d52553dfc9c40d8a11058b4 100644
--- a/net/disk_cache/disk_cache.h
+++ b/net/disk_cache/disk_cache.h
@@ -16,6 +16,7 @@
 #include "net/base/cache_type.h"
 #include "net/base/completion_callback.h"
 #include "net/base/net_export.h"
+#include "net/disk_cache/disk_cache.h"

[rvargas (doing something else), 2013/03/13 19:36:01]

ah?

[pasko-google - do not use, 2013/03/18 15:47:07]

Done.

 
 namespace base {
 class FilePath;
@@ -47,6 +48,20 @@ class Backend;
 // be invoked when a backend is available or a fatal error condition is reached.
 // The pointer to receive the |backend| must remain valid until the operation
 // completes (the callback is notified).
+NET_EXPORT int CreateCacheBackendWithFlags(
+    net::CacheType type,
+    const base::FilePath& path,
+    int max_bytes,
+    bool force,
+    uint32 flags,
+    base::MessageLoopProxy* thread,
+    net::NetLog* net_log,
+    Backend** backend,
+    const net::CompletionCallback& callback);
+
+// A slightly shorter version than the above. It is invoked from WebKit and

[rvargas (doing something else), 2013/03/13 19:36:01]

what is webkit?

[pasko-google - do not use, 2013/03/18 15:47:07]

oh, I incorrectly interpreted the linker error message, too many words. In fact
it was called from src/webkit/.. which is in the same repository and can be
changed in this CL.

Rephrased the comment.

+// requires a cleanup step there to eliminate.
+// TODO(pasko): eliminate this call.

[gavinp, 2013/03/13 18:36:12]

I think it's best if the stuff after the : is a full sentence, so capitalize the
"Eliminate." Also, to reduce repetitive redundant repetitions, eliminate all but
the first sentence from the comment, and expand the Todo a bit to something like
"Make cleanup changes in WebKit to eliminate this call" or something.

[pasko-google - do not use, 2013/03/18 15:47:07]

Agreed. Good general note. This time it does not require a cleanup though
because exposing flags to all callers of the method is unnecessary exposure. If
once backends start sharing flags we would probably introduce something like
disk_cache_internal.h

 NET_EXPORT int CreateCacheBackend(net::CacheType type,
                                   const base::FilePath& path,
                                   int max_bytes, bool force,
@@ -54,6 +69,10 @@ NET_EXPORT int CreateCacheBackend(net::CacheType type,
                                   net::NetLog* net_log, Backend** backend,
                                   const net::CompletionCallback& callback);
 
+// Renames cache directory synchronously and fires off a background cleanup
+// task. Used by cache creator itself or by backends for self-restart on error.
+bool DelayedCacheCleanup(const base::FilePath& full_path);

[rvargas (doing something else), 2013/03/13 19:36:01]

Why is this part of the interface?

[pasko-google - do not use, 2013/03/18 15:47:07]

It should not necessary be a part of a generic cache backend interface. I
resisted creating yet another header file that would be shared among backends,
and not shared with most common backend creation callsites.

Good name for such internal backend header file would be:
net/disk_cache/disk_cache_internal.h

Suitable interfaces to reside in it:
CreateCacheBackendForTesting()
disk_cache::BackendFlags
DelayedCacheCleanup()

What do you think?

[rvargas (doing something else), 2013/03/18 22:25:25]

How about cache_creator.h? There's already cache_util.h, disk_cache_test_base.h
and disk_cache_test_util.h (if this is only for tests)... better not to add
another generic sounding header.

Why do you want DelayedCacheCleanup() being accessible? I'm just curious, I
don't mind it (but cache_util already has something related).

as for the flags... it makes sense to share them, but so far they are extremely
implementation dependent (and that's why they are not exposed to formal users).
In other words, especial care is needed when dealing with them.

Another detail to consider is that not everything can be done with
CreateCBWithFlags... there is still special purpose code in disk_cache_test_base
that instantiates an object and does something with it before calling Init()
(showing that this was the original intended pattern, but I somewhat changed my
mind... or rather, the list of formal arguments grew over time).

Which leads me to believe that the internal creator maybe needs something like:

struct CreationParameters { type; size; flags; etc }
CreateBackend(parameters, &backend, callback);

So we would have the freedom to add as many things to the _internal_ parameters
as we want.

On a related note, I'm not sure I like to see automatic cleanup (force) being
part of such interface... I would prefer explicit users of the internal
interface to always have to deal with failures. But I guess it is just easier to
leave it there waiting for some weird use case to appear.

And I just realized that even this model doesn't work that well... what type
would we return? having to cast to get an _impl version is not good. I guess I
better read the rest of the CL.

[rvargas (doing something else), 2013/03/18 22:27:16]

In case it is not clear, this comment is basically stale given my last reply.

+
 // The root interface for a disk cache instance.
 class NET_EXPORT Backend {
  public: