Uploaded proposed changes.
http://codereview.chromium.org/18630

Why do you want to move only the cache data and not the cookies or history?. All the 
user-related data can be moved just by specifying a different profile directory with 
--user-data-dir=my_folder.

I am thinking of the general issue of separation between data types. Separation of 
data types based on source is a very new idea in the Windows world ( remember when 
app apps stored everything in their installation directory ? ) while the Unix-like 
systems at least separated "user owned" data from "system owned", since they had been 
built for multi-user operation from the ground.

Our thinking could be to separate the application data depending on several 
properties.

The cache is user-specific, since it is created in the context of the user. Even 
though the user owns the files, she is not interested in the cache, but the 
*performance* that it provides. This makes the cache into *application* data, which 
very well may be viewed as "installation" specific. Windows has the "Local storage" 
idea for this.

In contrast, the user's settings is typically something that should not change just 
because the user's files move around, so those need be in the "Roaming" profile.

Cookies can initially be regarded as a for of cache, but further thinking highlights 
a major difference. Many cookies contain information to help the user in navigation 
(even log in), in which case the cookies are more like "preferences" or "history", 
rather than "cache". This calls for a cookie storage policy of "Roaming".

Imagine now that the user has limited storage for personal files.
Imagine further that the user has his personal files synchronized with a server.

Browser caches take space. What if our user has 40 MB total storage allowed in her 
profile ? Easy, you say: move the entire browser profile ! But the "Local" storage is 
not important to save, as opposed to the "Roaming" storage, which contains data that 
defines the user's work points.
Copying the cache to, say, a local place on the hardware allows the user's settings - 
and with them, the Chromium preferences - to be copied along between different 
installations, while saving the time to copy unimportant files.

Even if most of the above apply to corporate users ( don't we use the Enterprise tag 
for this ? ) even home use is easier when the low priority data in the cache is moved 
off-profile. The profile can be backed up with no loss to the user, resulting in 
smaller backup archives that help performance ( less stolen time for comparisons, 
compression, encryption and copy ).

I can see that the user may lose the cache (by accident, managed updates, or by 
moving to a different machine), but still have her preferences and site specific data 
synchronized (or backed up). So yes, my view is still that the cookies and the cache 
represent two very different kinds of data that we may use - or allow - different 
storage policies for.

//

bug -> feature

I don't oppose the idea of having the cache in another drive, this would speed things  
in some cases. In other cases there is more space on a different drive.

However, my guess is that the right thing to do is to expose UI to change the 
location of the cache (like we do for the download dir) and keep a pointer in the 
profile for this location. I don't like the idea of being able to specify profile and 
cache separately on the command line. 

I agree fully to the idea of using a "visible" configuration for the cache. There are 
two reasons for taking the road over the command line:

The first is the obvious speed of implementation of the command line change. It is a 
low-risk, easily tested change with full return. Needless to say, I want this for 
myself because this lets me use the browser where its cache storage policy would 
otherwise stop me.

The second is that a change in the GUI needs careful consideration, which means quite 
a few discussions, and in the implementation phase, much more error-prone changes. 
The changes require testing and a review process which is more elaborate than in the 
case of the command line switch.

Given the nature of the change, it is more to regard as extra functionality, and I 
see that our resources are better spent on actual bugs than on adding infrequently 
used features. While I see that we can provide a "good enough" feature by the command 
line change to little effort, I can only see a GUI change as a "sometime in the 
future" addition.

I would love to find acceptance for this new option in the "under the hood" tab, and 
I would be very pleased to work with it.

In the meantime, though, having the functionality in place and accessible through the 
command line, gives that "good enough for the moment" feeling. :)

//

I also believe that the right thing to do is to have an extra setting under the hood 
to change the default values for cache location and maximum size.

I love this idea!
I'm using a ramdrive to put my firefox's cache in it. In some cases, like a heavy-
load and full-of-flash site, it does help my fx speed-up a lot.

Well :)
I'm happy to see the comments about the change, but do you (rvargas + cpu) really 
mean that this quick and miniature (after the latest review almost nil) change should 
never be done ... instead we should trust somebody to create the GUI change proposal 
?

I would like to see that decision, so that this feature can be closed and a new 
opened for the proposed GUI work. While I dislike your idea about this, I would still 
be happy to find acceptance for SOME method of providing the settings. I am ready for 
the GUI work too :)

//

Everyone seems to be missing the bigger issue. A browser cache is transistory, 
transient, temporary. You don’t keep it forever, and in fact clear it out to free up 
space, cover your naughty tracks, etc. Cookies, settings, and such are things you 
want to keep. It makes sense to be able to separate them.

(No comment was entered for this change.)

I don't really see the benefit to most users to set a different cache path (separate 
from user-data-dir). A command line switch is a reasonable alternative if it doesn't 
introduce code complexity.

Adding UI to the options panel is a separate bug.

“I don't really see the benefit to most users to set a different cache path (separate 
from user-data-dir).”

That’s probably because you have a drive big enough to store everything forever. Do 
you store your Documents and Settings on the same drive as Windows itself? If so, 
then you need to brush up on file organization, if not, then you should be able to 
see how it applies to this. (In fact, that Chrome insists on putting the application 
files in the user folder—for each user, thus wasting a lot of space—instead of 
putting them in a separate, central location is bad enough.)

I have uploaded a new change set, because I lost the cookie to the original one. The 
new set is a very minor change :)

http://codereview.chromium.org/21094

//

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=9375 

------------------------------------------------------------------------
r9375 | rvargas@google.com | 2009-02-06 17:58:42 -0800 (Fri, 06 Feb 2009) | 14 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/AUTHORS?r1=9375&r2=9374
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profile.cc?r1=9375&r2=9374
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=9375&r2=9374
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=9375&r2=9374

Adds a command line switch to allow the user to specify the location
of the disk cache, rather than in the profile directory. The command
line switch overrides the cache location regardless the chosen
profile.

In this implementation, the supplied directory name must should not
contain spaces.

BUG=6688

submitted by bekkra.
original code review http://codereview.chromium.org/21094/show


------------------------------------------------------------------------

(No comment was entered for this change.)

good

(No comment was entered for this change.)

Command line flags are only a partial solution, as they only affect Chrome when run explicitly.  However, as an example, clicking on a link in an email or other document will start the default browser using settings in the registry.  Unless the end user tweaks registry entries like HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command the cache directory will be the default when chrome is started from a link.

In my case my boot drive is an SSD, so I want the cache always to be on a different drive both for space considerations and to prolong drive life.  In addition, I use Allway Sync to replicate my user directory to a backup location, and don't need to be replicating the cache.

Until this can be made a true UI setting, please consider implementing it in the about:flags 

#58, I have the same problem. I solved it using junction points (symbolic links à la Windows): http://en.wikipedia.org/wiki/NTFS_junction_point