Redo the Storage Partition directory layout to support guest tags and origin based partitions.

chrome/browser/profiles/profile_impl_io_data.cc

Index: chrome/browser/profiles/profile_impl_io_data.cc
diff --git a/chrome/browser/profiles/profile_impl_io_data.cc b/chrome/browser/profiles/profile_impl_io_data.cc
index ed274946a3c4bf3c42edc26a8c904aa02783de54..2465441a1efd5b433fb039dfd103d4617d917ac9 100644
--- a/chrome/browser/profiles/profile_impl_io_data.cc
+++ b/chrome/browser/profiles/profile_impl_io_data.cc
@@ -32,6 +32,7 @@
 #include "content/public/browser/browser_thread.h"
 #include "content/public/browser/notification_service.h"
 #include "content/public/browser/resource_context.h"
+#include "content/public/browser/storage_partition.h"
 #include "net/base/server_bound_cert_service.h"
 #include "net/ftp/ftp_network_layer.h"
 #include "net/http/http_cache.h"
@@ -95,7 +96,7 @@ void ProfileImplIOData::Handle::Init(
       const FilePath& media_cache_path,
       int media_cache_max_size,
       const FilePath& extensions_cookie_path,
-      const FilePath& app_path,
+      const FilePath& profile_path,
       const FilePath& infinite_cache_path,
       chrome_browser_net::Predictor* predictor,
       PrefService* local_state,
@@ -121,9 +122,9 @@ void ProfileImplIOData::Handle::Init(
 
   io_data_->lazy_params_.reset(lazy_params);
 
-  // Keep track of isolated app path and cache sizes separately so we can use
-  // them on demand.
-  io_data_->app_path_ = app_path;
+  // Keep track of profile path and cache sizes separately so we can use them
+  // on demand when creating storage isolated URLRequestContextGetters.
+  io_data_->profile_path_ = profile_path;
   io_data_->app_cache_max_size_ = cache_max_size;
   io_data_->app_media_cache_max_size_ = media_cache_max_size;
 
@@ -513,7 +514,9 @@ ProfileImplIOData::InitializeAppRequestContext(
   AppRequestContext* context = new AppRequestContext(load_time_stats());
   context->CopyFrom(main_context);
 
-  FilePath app_path = app_path_.AppendASCII(app_id);
+  FilePath app_path =
+      content::StoragePartition::GetPartitionPath(profile_path_, app_id);

[willchan no longer on Chromium, 2012/09/14 23:52:45]

One thing that was sort of nice about the previous app_path thing is it was very
clearly a subdirectory. Here, this could return anything. Is it possible to get
this to append a relative path, rather than return an absolute path?

[awong, 2012/09/14 23:56:26]

Not sure how I'd do that without shifting some of the path creation logic out of
GetPartitionPath().  How is this not a subdirectory path?  I can't see why this
is any different from before...

Note that long term (probably second week of october), I'm going to start
working on removing this set of stuff from ProfileImplIOData.

[willchan no longer on Chromium, 2012/09/15 00:02:55]

Perhaps I'm confused? In the previous code, we have X = Y + Z;
In the new code, we have X = f(Y,Z);

In the former, X is clearly a subdirectory of Y. In the latter, that's not true.
Can you clarify what that means?

[willchan no longer on Chromium, 2012/09/15 00:03:44]

Fyi, I didn't read content::StoragePartition::GetPartitionPath(). So I have no
idea what it does. I looks like some function f() which could return anything.

[awong, 2012/09/15 00:08:00]

Ah, I see what you mean.  I want StoragePartition to own all the logic of how to
figure out where on disk this stuff sits.  Letting ProfileIODataImpl make
statements like the first one, that X is a subdirectory of Y, is an abstraction
break.  Hiding that detail is actually good here IMO.
As part of StorageIsolation, I want all code to retrieve the
URLRequestContextGetter() via the StoragePartition object.  I also want
StoragePartition to control the lifetime of the various
URLRequestContextGetters.  There's a lot of tangled lifetimes going on here , so
I don't have a completely clear roadmap, but at the end of this all the
following APIs should disappear:
  BrowserContext:GetRequestContext()
  BrowserContext:GetMediaRequestContext()
  BrowserContext:RequestContextForRenderProcess()

Consequently all the supporting logic in ProfileImplIOData (this included)
should go away.

[willchan no longer on Chromium, 2012/09/15 00:13:26]

Can you clarify this? Don't all storage partitions belong to some profile? If
that's the case, shouldn't all storage partitions (X) be in a subdirectory under
the profile path (Y)?

I guess I'm surprised it's not something like X = Y + f(Y,Z).

[awong, 2012/09/15 00:43:07]

Updated to be a relative path.

+
   FilePath cookie_path = app_path.Append(chrome::kCookieFilename);
   FilePath cache_path = app_path.Append(chrome::kCacheDirname);
 
@@ -586,7 +589,8 @@ ProfileImplIOData::InitializeMediaRequestContext(
   MediaRequestContext* context = new MediaRequestContext(load_time_stats());
   context->CopyFrom(original_context);
 
-  FilePath app_path = app_path_.AppendASCII(app_id);
+  FilePath app_path =
+      content::StoragePartition::GetPartitionPath(profile_path_, app_id);
   FilePath cache_path;
   int cache_max_size = app_media_cache_max_size_;
   if (app_id.empty()) {