А куда девать настройки из шапки списка "Т"? Предлагаешь собрать все в одну кучу в списке "Н", где новички и так теряются в куче непонятных им галок и полей? Хочешь усугубить и без того навороченный интерфейс?

P.S. Если уж идти по пути уменьшения количества списков, то я за предложение, озвученное Кириллом - "Двусписочная система: классификатор трафика и политика фильтрации"...

А Кирилл и не предлагал совсем избавиться от существующих списков - он предлагал оставить их на "нижнем уровне"! Следовательно, все их настройки останутся при них...


Это был прозрачный намек на то, что возможности mai62 в плане времени не безграничны и что хорошо бы, если бы какой-то программист-доброволец (например, сам автор рац.предложения - Кирилл) написал приблуду, которая бы воплотила его идеи в жизнь!
После чего в процессе тестовой эксплуатации уже можно будет определить ее удобство для широких масс пользователей и необходима ли ее интеграция в HC...


Согласен, дублирование некоторых правил Т в Н имеет место быть, но это вовсе не означает, что Т без Н нельзя использовать!

Ну, например, у пользователя напряг с финансами и он внес в вписок Т данные, которые он не хочет постоянно видеть - скажем, информеры и графики курсов валют, котировки акций и т.п., которые обновляются скриптом ежеминутно по переменным URL.
Но раз в день (или когда захочет) он все-таки отключает список Т и хочет видеть свежую информацию на текущий момент, при этом его не интересуют данные из кэша, т.к. они уже устарели - ему нужен "свежак"!
При таком раскладе указанных правил списка Т не только не будет в списке Н - они не нужны даже в списке З - зачем лишние файлы в кэше, если пользователь желает видеть только самые свежие котировки или ничего, дабы не дезинформироваться!

А причем тут "весь остальной HC"? Речь шла о том, чтобы написать конвертер из двусписочной системы в существующие списки HC. В этом конвертере создаем списки категорий и действий, как было предложено Кириллом.
Затем нажимаем кнопку "Конвертировать" и получаем готовый набор списков HC в текущем формате! Их подсовываем HC и можем тестировать!

Цель - подтвердить на практике преимущества двусписочной системы, а именно удобство создания, настройки, использования, распространения и т.д.
Подцель - ускорить реализацию предложения (интеграцию в HC), не напрягая mai62.


Предчувствовал, что последует такое предложение...

Если отключать весь ЧС, то вместе с информерами пролезет и вся реклама, что не приемлемо!
Отключать только отдельные правила не удобно, так как их может быть много, а горячие клавиши для отдельных (группы) правил не предусмотрены!
Вот и оcтается использовать список Т...

Это не одно и то же! Эти картинки в большинстве случаев могут быть мне полезны/интересны, т.к. всю рекламу уже вырезал ЧС !
Кроме того, в Т может и не быть стандартных правил для картинок! Я уже упоминал об информерах с переменным URL и нестандартным расширением...


Без этого вполне можно обойтись, если места на диске не жалко...

Ты уходишь в сторону! Здесь мы обсуждаем самодостаточность списка Т и возможность его функционирования без Н, а не нюансы использования списков Ч, 3, Б !

Всегда! Картинки в большинстве своем статичные - раз загрузил в кэш и смотри их хоть тысячу раз совершенно бесплатно!
Информеры всегда динамичные - при каждой загрузке получаем новый расход трафика!


Готов согласиться, что можно совместить функции Н и Т в одном списке, но сделать это получится только ценой усложнения интерфейса - настроек списка Н, которые уже давно вышли из разряда интуитивно понятных без документации!

При таком "реальном хождении по Интернет" зачем вообще нужен кэширующий прокси?! Давай без перегибов!


Я уже поднимал этот вопрос больше года назад! Ответ mai62 был такой:


Согласен. CONNECT мы вообще не умеем кэшировать, а POST кэшировать скорее вредно, чем полезно! Соответственно, не нужна и аналогичная галка в списке "Запись в кэш", т.к. ИМХО, она должна быть включена всегда!


Кто ж против! mai62 уже давно думает над реализацией плагинной системы!

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

Да и само опнятие "свежие файлы" уже давно не соответствует действительности! Можно считать "свежими" файлы с критерием свежести - год? ИМХО, нет! Но опция отключает и эти правила без разбору!

ИМХО, блок настроек "свежих файлов" - пережиток прошлого, который можно бы уже упразднить или оставить только глубоко в недрах INI...


Это не помешает во всех списках. Опиши в "Новых предложения", как ты видишь реализацию данной возможности:
- где и как настраивать клавиши (интерфейс),
- где и как хранить настройки клавиш,
- какие виды клавиш будут (временные или/и постоянные?) и какое количество (по 1 каждого вида или больше?),
- присваивать клавиши можно будет группе (как их группировать?) или каждому правилу в отдельности 
и т.д.


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

Есть же уже отдельная тема: "Плагины к НС", где обозначены основные направления!