Радик245
Я говорю о ситуации когда нам нужно заблокировать site.com, site.ru, site.us, site.com.ua правилом ||site.~^^, но не трогать site.name.org (в данном случае site субдомент name.org). В принципе это решаемо условием $domain=~name.org или если name.org сидит на множестве доменов первого уровня, то $domain=~name.~^.
Вообще вероятность такого события довольно мала. У нас уже есть пачка общих правил вида ||site. и ещё ни к одному не пришлось приделать исключение из-за того, что оно что-то лишнее блокирует.

Отредактировано Lain_13 (09-02-2011 13:07:01)

После дополнительного размышлений я пришёл к выводу, что маска ~^ в качестве MagicTLD может быть полезной исключительно в случаях когда нужно указать на то, что искомая строка идёт сразу после домена первого уровня (вроде .ru/banners/). Если мы не можем с её помощью отличить site.ru от site.name.org в правиле ||site.~^^, то с таким же успехом мы можем использовать просто правила вида ||site. и делать исключения по доменам. Хотя, как я уже говорил, это позволяет чётко указывать уровень вложенности элементов, а не как сейчас с маской «*».
в domain-исключениях от ~^ тоже не много толку. С таким же успехом там могла бы работать маска «*».

Добавлено 09-02-2011 16:28:42
С другой стороны если точку исключить из подходящих для ~^ символов (т.е. не полный антипод ^), то в качестве MagicTLD и маски для domain-ограничений она могла бы работать вполне успешно.

Отредактировано Lain_13 (09-02-2011 16:26:15)

Радик245
Нет, боюсь это тоже не годится. В имени любого «каталога» или «файла» может быть любое количество точек. Это значит, что указав /@.@| после домена мы заблокируем только файлы с одной точкой в имени. Достаточно добавить разное количество точек в имена файлов и вся польза от этой маски накрывается медным тазом.

Т.е. одновременно как MagicTLD и как антипод «^» у этой маски работать не получится, а жаль.

Lain_13
Ну я ведь все-таки скорость замерял. В Firefox 3.6 получалось ускорение на почти 50%, а в Firefox 4 и вовсе в два раза.

Радик245
А какой смысл у такого запрета? Другие (более длинные) ключевые слова и так уже предпочитаются. А правило, для которого ключевое слово не найдено, приходится проверять всегда.

Владимиp Палант

Это уже есть в тестовых версиях?

Добавлено 11-02-2011 16:26:45
Lain_13
http://adblockplus.org/development-builds/

То есть скорее всего откладывается.

Отредактировано Радик245 (11-02-2011 16:27:32)

Владимиp Палант
Хорошо! А то Lain_13 уже делает правила без учёта нынешнего алгоритма оптимизации и таких в RuAdList+EasyList уже больше двадцати.

Спасибо!

Да, думаю, можно и ||dverizamki.org$object
Такие правила, как
||dw.com.com^$third-party
||cc-dt.com^$third-party
,  можно заменить на
://dw.com.com/
.cc-dt.com/$third-party
для ускорения проверки. ||cc-dt.com^$third-party - в изилисте.

Отредактировано Радик245 (14-02-2011 18:31:31)

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

||clickserve.cc-dt.com^$third-party
://dw.com.com/redir^

Но не уверен, что это всё.

Кажется, в ABP такое и не работает.

Добавлено 14-02-2011 19:44:40
Владимиp Палант

Я знаю, что Вы в очередной раз хотите сказать, что нельзя закреплять алгоритм оптимизации в правилах.
Но ведь всё равно при переходе на новый алгоритм оптимизации приходится переделывать часть правил.

Владимиp Палант
Ну я бы сказал, что у нас довольно часто попадается ситуация в общих правилах когда мы перебираем довольно много вариантов + регулярка привязанная к ключевому слову может куда больше чем простое правило блокировки. Ведь простые правила не могут перебирать варианты, они вообще много чего не могут. Это не только оптимизация, это ещё и удобство. С другой стороны обычные регулярки могут многое, но при этом они в таком положении, что мы должны избегать их создания любыми путями. Какой смысл в их поддержке если их столько времени уже невозможно использовать без отрицательных последствий? Может давай совсем их поддержку выкинем? Всё равно же их использовать крайне нежелательно и вместо них будем клепать по 40 правил отличающихся парой знаков или числом.

Радик245
> Кажется, в ABP такое и не работает.
Это не зависит от ABP, а от движка регулярок в браузере. Он умеет.

Добавлено 15-02-2011 00:11:26
Кстати, мой способ не предполагает закрепления алгоритма оптимизации. Если ключевые слова будут искаться иным путём, то можно будет изменить обработчик для #…#/…/ и блок между #…# парсить иначе. Возможно этот блок придётся изменить в подписке, но только и всего. Мы и так ворох правил переделали и столько ещё переделаем…

Такая регулярка не очень укладывается в оптимизатор на самом деле. Варианты с цифрами не будут давать ключевого слова baner.
А, да ладно, обойдёмся без регулярок.

Радик245
В данном случае 5 правил пока хватает. Конечно при их проверке не выгодно проверять 5 регулярок вместо одной, но Владимир прав — такая микрооптимизация бесполезна.
Ну их, эти регулярки. Я был раздражен когда то писал.

Хотя иметь возможность пользоваться регулярками как обычными правилами было бы приятно. А то они что есть, что их нет.

Отредактировано Lain_13 (15-02-2011 16:21:08)