[BlobAsync] Disk support for blob storage

storage/browser/blob/blob_flattener.h

+// Copyright 2016 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 STORAGE_BROWSER_BLOB_BLOB_FLATTENER_H_
+#define STORAGE_BROWSER_BLOB_BLOB_FLATTENER_H_
+
+#include <map>
+#include <string>
+#include <utility>
+
+#include "base/macros.h"
+#include "base/numerics/safe_math.h"
+#include "storage/browser/blob/blob_storage_registry.h"
+#include "storage/browser/storage_browser_export.h"
+
+namespace storage {
+class BlobDataBuilder;
+class InternalBlobData;
+
+// This class takes a BlobDataBuilder which can contain blob references and
+// 'flattens' these references out. The resulting flattened blob (both regular
+// items and items from other blobs) is put into the |output_blob|. We keep
+// track of edge cases like partial slicing on data or pending file entries,
+// and calculate the total & required memory for this blob.
+struct STORAGE_EXPORT BlobFlattener {

[kinuko, 2016/07/17 16:15:46]

Btw this seems to do more than just flattening out blob references, converting
BlobDataBuilder items into InternalBlobData representation seems to be the main
task (while also flattening blob references) to me.

[kinuko, 2016/07/17 16:15:46]

Is the only user of this struct BlobStorageContext?  (I'm not a big fan of
introducing many non-private utility classes if it's used only in one call site
as it's unclear the scope of this class... could this be just some utility
function / static method?)

[dmurph, 2016/07/19 02:26:27]

Same problem as BlobSlice, where we need 5 output variables (even if we change
the booleans to a status), so we might as well have a struct output. I like the
ability to test it by itself as well.

+  BlobFlattener(const BlobDataBuilder& transportation_result,

[kinuko, 2016/07/17 16:15:46]

nit: On the callsite we just call the builder 'content' while here we use much
more specific parameter name (transportation_result), which feels a bit weird.

I'd probably just use input_builder or something at both places ('result' could
sound like output parameter, and 'content' feels too generic)

[dmurph, 2016/07/19 02:26:27]

Done.

+                InternalBlobData* output_blob,
+                BlobStorageRegistry* registry);
+  ~BlobFlattener();
+
+  // References didn't exist, the reference offset/size were invalid, or we were
+  // referencing ourself.
+  bool contains_invalid_references = false;
+  // A references was broken, so we should be broken.
+  bool contains_broken_references = false;
+
+  // The input builder has an item with type TYPE_BYTES_DESCRIPTION or TYPE_FILE
+  // with the path == BlobDataBuilder::kAppendFutureFileTemporaryFileName.
+  // (These occur when one calls AppendFutureData or AppendFutureFile on the
+  // builder).
+  bool contains_pending_content = false;

[kinuko, 2016/07/17 16:15:46]

Could these three bools be just captured as a single BlobStatus value? (DONE/OK,
PENDING_DATA_POPULATION, INVALID_CONSTRUCTION_ARGUMENTS or
REFERENCED_BLOB_BROKEN)

[dmurph, 2016/07/19 02:26:27]

Done.

+
+  // This is the total size of the blob, including all memory, files, etc.
+  base::CheckedNumeric<uint64_t> total_size;
+  // This is the new memory needed to construct the blob, including both memory
+  // items as well as copies from other blobs.
+  base::CheckedNumeric<uint64_t> memory_needed;
+
+  // This contains all blobs referenced.
+  std::vector<std::pair<std::string, BlobStorageRegistry::Entry*>>
+      dependent_blobs;
+
+  // These record all future copies we'll need to do from referenced blobs. This
+  // happens when we do a partial slice from a pending data or file item.
+  std::vector<BlobStorageRegistry::ItemCopyEntry> copies;
+};
+
+}  // namespace storage
+#endif  // STORAGE_BROWSER_BLOB_BLOB_FLATTENER_H_