А для чего "пользуемся"? Ты можешь привести конкретный пример из жизни, когда нужны исключения для записи в кэш не по размеру файла (на это никто не посягает), а в зависимости от типа файла или сайта на котором он находится? Я думаю, что такие примеры должны быть, однако в моей практике они не встречаются.

2 Rick
А я не кеширую веб-интерфейс почтовых клиентов, новостные ленты и результаты поиска.

Вот например ссылка +web.icq.com/whitepages/online - показывает текуший статус icq. Т.е. конкретная ссылка на конкретный путь на конкретном сайте.
в кеш её писать нафиг, ибо в оффлайне она смысла не имеет, однако в браузер пропустить надо.
Разумеется можно и в исключение к .* все такие ссылки запихать - но их там не видно, за край поля  уезжают.

Oneri
По моему, надо смотреть на жизненность ситуации: реально может быть нужно запретить запись в кэш лишь нескольких типов данных. Все их можно уложить в одном правиле. Запрет записи в кэш конкретных данных на конкретных сайтах, на мой взгляд, не нужен, по соображениям, изложенным здесь и здесь.
Как раз сейчас в этом топике и "очень сильно думаем". Почему думать надо когда-то в неопределенном будущем?
В чем именно ты видишь снижение функционала?
Если есть у тебя такое предложение - вынеси его отдельной темой (только без "я бы больше понял бы" ). На мой взгляд, резон есть.

Rick
Тогда я недопонял, о чем в примере Кирилла речь. Можешь привести набор правил, соответствующий его примеру?
Понимаешь, на мой взгляд, должен быть четкий баланс между тем, что хочется пользователю и назначением программы. Если мы его смещаем в сторону удобства реализации любого желания пользователя, не относящегося к экономии трафика/времени, то приходим к неминуемому усложнению и перемешиванию логической структуры программы (при наличии в БС галок "Запись в кэш" и "Преобразование URL" мы заносим в Белый список правила, не имеющие никакого отношения к экономии трафика/времени - вспомогательные правила, относящиеся чисто к управлению кэшем). Это влечет усложнение понимания общей логики программы неподготовленным пользователем и увеличение риска совершить ошибку для любого пользователя.
Если, например, желание пользователя получить еще более тонкий инструмент начнет простираться на управление чтением из кэша, то он захочет поиметь в БС колонку, позволяющую ограничивать чтение из кэша для определенных типов данных. Аналогично в БС могут появиться колонки для "не сохранять маленькие файлы", "не сохранять большие файлы", "сохранять WWW для URL", "игнорировать No-cache", "удалять ссылку на порт 80 из имени файла в кэше" и совсем уж гипертрофируя, "разрешить запись в RAM-кэш".
Инструмент стал заточенным как бритва (в кэш попадает все меньше ненужного), однако рука, держащая эту бритву, стала проявлять признаки болезни Паркинсона - риск сделать ошибку стремительно взлетел. Разобраться при этом в списке стало нереально. А получили ли мы при всем этом хоть на грамм увеличения экономии трафика/времени? Нет!
Именно поэтому мое видение сводится к варианту, когда БС не должен брать на себя функций, не связанных с назначением программы (экономией трафика/времени). Вся же остальная заточка, не способствующая этой экономии, должна быть жестко ограничена. Вычистить ненужное из кэша мы можем и постобработкой, не усложняя общей логики программы.

Сорри, я имел в виду пример Дем'а: +web.icq.com/whitepages/online - ограничивается сайт/страница, а не какой-то тип.

Значит, чтобы "не смешивать", нужно на вкладке управления кэшем делать возможность ввести не одно исключение, а несколько, т.е. получить тот же список "З", значит, нужно оставить список "З" как он есть и не городить огород.

Да и пожалуйста. Представь: списка "З" нет, есть только галочка "кэшировать все", а исключения, если они нужны, задаются в БС совершенно так же как и сейчас.
Если же тебе нужно задать не исключения для записи в кэш, а наоборот: указать что именно следует записывать в кэш - то, указываешь в БС это "что именно" как исключение для правила ".*" с отмеченным списком "З".

Не понял. Зачем? Предлагается вообще убрать список Запись в кэш - он излишен.

Не согласен. Единая "панель управления" т.е. Белый список удобнее. Например правило для Белого списка:
Здесь же и запрет на кэширование. А так как ты предлагаешь - нужно еще и дублировать это правило на вкладке управления кэшем.

Михаил
Лично я согласен (ты убедил) с ненужностью списка "Запись в кэш", но считаю правильным и необходимым сохранить в БС графу "З". Т.е. список "З" убирается, опции "Разрешить запись в кэш" (= кэшировать все) и "Только для GET-запросов" переносятся на вкладку управления кэшированием. Все остальное остается как есть. Т.е. видимо то, что у тебя идет первым вариантом.
Это обеспечивает:
1. Разумное "облегчение" программы;
2. Требует минимальных переделок (ломать не строить);
3. Пользователям не придется радикально менять свои приемы работы с НС.

И небольшое отступление от текущего вопроса: ты все-время ссылаешься на некие цели некоего гипотетического пользователя, но совершенно упускаешь из виду, что разные пользователи по-разному воспринимают НС: для кого-то это "экономилка", для кого-то "кеширка/оффлайн-браузер", для третьих - прокси-сервер. Программа универсальна и используется с разными целями разными пользователями. Вывод таков, что чем более универсальные решения - тем имхо лучше для всех.

Лукавишь

ОК. Завтра добавлю.

Поживем - увидим. А вообще, что если отказаться от уже имеющихся рамок интерфейса НС и попытаться построить интерфейс с нуля - что видится? Только если будут мысли - в новом топике плз.