Adding URLResponse Disk Cache to mojo.

mojo/services/service_cache/public/interfaces/service_cache.mojom

Index: mojo/services/service_cache/public/interfaces/service_cache.mojom
diff --git a/mojo/services/service_cache/public/interfaces/service_cache.mojom b/mojo/services/service_cache/public/interfaces/service_cache.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..6cead598b21edc5944f8fdf2cc47e81fe0afd541
--- /dev/null
+++ b/mojo/services/service_cache/public/interfaces/service_cache.mojom
@@ -0,0 +1,29 @@
+// 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.
+
+module mojo.service_cache;
+
+import "mojo/services/network/public/interfaces/url_loader.mojom";
+
+// This service allows the mojo shell and content handler to efficiently cache

[blundell, 2015/05/07 11:29:21]

I would expand on this comment to reflect our offline discussion that this is
really about caching URLResponses on disk.

[qsr, 2015/05/07 12:49:02]

Done.

+// and retrieve mojo applications.
+// TODO(qsr): At the moment, the service cache only handles ETag. It should
+// also handles all the other http cache mechanisms.

[blundell, 2015/05/07 11:29:21]

I would expand on this to be more explicit about what the current policy is on
when the cached entry will be invalidated. IIUC, it's this:
- If the response and the cached entry have etags, the etag contents will be
used to determine whether to invalidate the entry.
- In all other cases, the cached entry will always be regarded as invalid.

Is that correct? In other words, the lack of handling of other caching
mechanisms is a performance issue, not a correctness issue.

[qsr, 2015/05/07 12:49:02]

Comment extended. And yes this is correct, the cache is correct, but could cache
more.

+interface ServiceCache {
+
+   // Given a URLResponse, returns a pair of path. |file_path| is a file

[blundell, 2015/05/07 11:29:21]

nit: s/path/paths

[blundell, 2015/05/07 11:29:21]

s/path/paths

[qsr, 2015/05/07 12:49:02]

Done.

[qsr, 2015/05/07 12:49:02]

Done.

+   // containing the body of the response. |cache_dir_path| is a directory that
+   // the applicaton can use to store content. This service guarantee that

[blundell, 2015/05/07 11:29:21]

Since it's a little opaque why |cache_dir_path| is involved, I would give an
example usage of this ("e.g., a content handler that is backed by a VM that
compiles files could have the VM use this directory to cache the compiled
files").

[qsr, 2015/05/07 12:49:02]

Done.

+   // |cache_dir_path| will be emptied when |file_path| content changes.
+   GetFile(mojo.URLResponse response) =>
+       (array<uint8>? file_path, array<uint8>? cache_dir_path);
+
+   // Given a URLResponse that is expected to have a zipped body, returns a
+   // pair of path. |extracted_dir_path| is a directory containing the unzipped
+   // body of the response. |cache_dir_path| is a directory that the applicaton
+   // can use to store content. This service guarantee that |cache_dir_path|
+   // will be emptied when |extracted_dir_path| content changes.
+   GetExtractedContent(mojo.URLResponse response) =>
+       (array<uint8>? extracted_dir_path, array<uint8>? cache_dir_path);
+};