+  HandyCache форум
|-+  Главная категория» Новые предложения» Структура кэша. Можно ли усовершенствовать?
Имя пользователя:
Пароль:
Страниц: 1 2 3 [Все]   Вниз
« предыдущая тема следующая тема »
  Отправить эту тему    Печать  
Автор Тема: Структура кэша. Можно ли усовершенствовать?  (Прочитано 35617 раз)
0 Пользователей и 1 Гость смотрят эту тему.
tea
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« : 05 ноября 2007, 18:38:47 »
Можно ли сделать так, чтобы HandyCache сохранял в кэше домены третьего и более уровней как папки?

Например, сейчас у меня есть папка dia.sf.net, а надо чтобы было: sf.net\dia\

На крайний случай можно ли использовать домены как папки, т.е. net\sf\dia\ и т.п.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #1 : 05 ноября 2007, 20:03:19 »
Цитата: tea от 05 ноября 2007, 18:38:47
Можно ли сделать так, чтобы HandyCache сохранял в кэше домены третьего и более уровней как папки?

Можно через список "Преобразование URL".

Например, вот такое простое правило:
#5#~#True#~#^([^/]+)\.([^./]+\.[^./]+)#~#\2/\1#~#False#~#True
ставит домен 3 и выше уровня после имени сайта, т.е.: 
dia.sf.net/aaa/pic.gif  станет  sf.net/dia/aaa/pic.gif
domen4.dia.sf.net/aaa/pic.gif  станет  sf.net/domen4.dia/aaa/pic.gif

Если хочешь сделать домен 4 и выше уровней тоже отдельными папками, то доделай правило по аналогии.


Вообще, в теме "Алгоритм преобразования URL в имя файла в кэше" уже обсуждалось нечто похожее в плане встраивания подобного алгоритма в будущие версии HC...
Сообщить модератору   Записан
tea
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #2 : 06 ноября 2007, 03:09:50 »
А как же 68.183.62.55 ?
Такие адреса должны сохраняться как есть.

Вообще, хотелось бы какой-нибудь универсальности, так как сейчас, насколько я понял, для адресов с разным количеством доменов придётся писать отдельные правила.

P.S.:
В RegExp не силён — аналогию для четвёртого домена, придумывал весь вечер, но до сих пор не пойму как работает.
Поэтому, если возможно то, что прошу, дайте сразу правило.  Смущен
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #3 : 06 ноября 2007, 22:06:47 »
Вставь в "Преобразование URL" вместо того правила вот эти два подряд в указанном порядке:

#5#~#True#~#^(([^./]+)\.)?(([^./]+)\.)?(([^./]+)\.)?(([^./]+)\.)?([^./]+)\.([^./]+\.[^./\d]+)/#~#\10/\9/\8/\6/\4/\2/#~#False#~#True

#5#~#True#~#//+#~#/#~#False#~#False

Обрабатывает домены до 7-го уровня включительно. IP в URL не трогает.
« Последнее редактирование: 08 декабря 2007, 13:04:10 от DenZzz » Сообщить модератору   Записан
tea
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #4 : 08 ноября 2007, 03:11:57 »
Спасибо!  Отлично!
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621
« Ответ #5 : 08 ноября 2007, 11:26:35 »
Цитата: DenZzz от 05 ноября 2007, 20:03:19
dia.sf.net/aaa/pic.gif  станет  sf.net/dia/aaa/pic.gif

А если на сайте sf.net уже есть папочка dia ?
Возникнет каша. Надо чтобы преобразование было взаимно-однозначным. Чтобы по файлу в кэше было возможно узнать его URL.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #6 : 08 ноября 2007, 12:54:27 »
Цитата: Сергей от 08 ноября 2007, 11:26:35
Возникнет каша. Надо чтобы преобразование было взаимно-однозначным. Чтобы по файлу в кэше было возможно узнать его URL.

tea просил отдельные папки - он их получил!

Вероятность совпадения имени домена и папки в URL не велика. Обратное преобразование требуется не всем! Кроме того, при использовании списка "Преобразование URL" обратное преобразование часто однозначно не обратимо!

А при желании простой правкой правила, приведенного выше, можно папки доменов в кэше помечать каким-нибудь спец.символом...
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621
« Ответ #7 : 08 ноября 2007, 13:42:16 »
Вероятность намного выше нуля, поэтому лучше это предусмотреть. Чтобы потом не вылезли неожиданные  глюки.

Изначально хотелось прогонять через список преобразования не URL а собственно путь к файлу. Тогда это было бы более мощным инструментом по управлению местом хранения данных. Жаль что автору не понравилась эта идея.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #8 : 08 ноября 2007, 19:40:24 »
Цитата: Сергей от 08 ноября 2007, 13:42:16
Вероятность намного выше нуля, поэтому лучше это предусмотреть. Чтобы потом не вылезли неожиданные  глюки.

Я бы сказал, вероятность стремится к нулю! Есть реальные примеры таких совпадений и вылезших потом глюков?

В любом случае у пользователя всегда есть выбор отказаться от необратимых преобразований простым отключением списка "Преобразование URL"...

Цитировать
Изначально хотелось прогонять через список преобразования не URL а собственно путь к файлу. Тогда это было бы более мощным инструментом по управлению местом хранения данных.

Чем не устраивает текущая функциональность? Есть  реальная необходимость в "более мощных инструментах"?
Сообщить модератору   Записан
tea
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #9 : 08 ноября 2007, 20:03:43 »
Сергей, Вы не поверите, но мне совпадение имени папки и домена очень полезно.
Вопрос возник после того, как я однажды залез в папку кеша. HD у меня большой, кеш чищу редко — по настоящему ещё ни разу, поэтому там я увидел там «миллион» папок *.imgshake.com или что-то подобное.
В самой же папке img386.imgshake.com находится папка img386 (тот самый случай, о котором вы предупреждаете), а в ней только один файл, такое же в папке-домене img431.*.*, и т.д. (там кажется лежат аватары с какого-то часто посещаемого мною форума).
По второму разу закачивать этот хлам совсем не хочется, а если он перезатрётся — я не заплачу.

У меня HC работает как именно для кеша, чтобы не тянуть лишнего с интернета, поэтому обратное преобразование адреса мне ещё ни разу не понадобилось, сохранять полную структуру сайта сильной надобности также не возникало.
Вариант же, что в домене dia.sf.net будет лежать file1, и файл с другим содержимым, но с таким же именем лежит по адресу sf.net/dia/ для меня всё равно кажется меньшим злом, так как при новой организации кеша, я могу зайти папку домена, и уже там искать то, что когда читал, скачивал, а сейчас кроме того, что это было в новостях mail.ru уже ничего другого не помню.
Раньше приходилось искать по всему кешу…

Одно только уточнение: важно ли, в каком месте списка стоят эти правила — в конце или в начале? (Просто, вот это ваше «(?<=/)/» меня сильно настораживает — я не понимаю что оно делает  Непонимаю)
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #10 : 08 ноября 2007, 23:45:40 »
Цитата: tea от 08 ноября 2007, 20:03:43
я увидел там «миллион» папок *.imgshake.com или что-то подобное.

Для отбрасывания этого и подобного мусора в дефолтных списках давно существует правило:

#5#~#True#~#^(galler(ies|y)|im?a?(ge?s?)?|(f|ph)ot(ki|os?)|pi(cs?|x)|tbn|www)\d+\.(?!.{2,4}/)#~##~#False#~#True

Поставь его в начало списка "Преобразование URL".

Цитировать
В самой же папке img386.imgshake.com находится папка img386

Если не добавишь правило выше, то тогда у тебя в кэше будет 2 папки img386:  imgshake.com\img386\img386\...

Цитировать
Одно только уточнение: важно ли, в каком месте списка стоят эти правила — в конце или в начале?

Да. Порядок правил в списке "Преобразование URL" имеет значение, поэтому я всегда указываю в каком порядке вставлять правила и куда!
Сообщить модератору   Записан
tea
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #11 : 09 ноября 2007, 00:56:32 »
Дефолтные списки я не трогал — это правило у меня стоит третьим, но img*.img*.com всё-таки присутствовали.

Два новых правила сейчас стоят последними.

Цитировать
в кэше будет 2 папки img386:  imgshake.com\img386\img386\...

Для меня это не принципиально, главное что в папке самого кеша этих папок не будет. Так их удалять легче.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #12 : 09 ноября 2007, 09:53:02 »
Цитата: tea от 09 ноября 2007, 00:56:32
Дефолтные списки я не трогал — это правило у меня стоит третьим, но img*.img*.com всё-таки присутствовали.

То правило должно резать домены 3-го уровня вида img<число> ! Возможно, эти папки в кэше появились у тебя еще до добавления третьего правила...
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621
« Ответ #13 : 09 ноября 2007, 13:33:33 »
Цитата: DenZzz от 08 ноября 2007, 19:40:24
Есть  реальная необходимость в "более мощных инструментах"?
Например раскидывать разные сайты или типы файлов в разные папки на нескольких дисках, а не пихать все в одну большую папку кэша. Например, сделать чтобы файлы mp3 сохранялись не в папке кэша а сразу на диск с музыкой.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513
« Ответ #14 : 10 ноября 2007, 08:01:28 »
Цитата: tea от 08 ноября 2007, 20:03:43
Одно только уточнение: важно ли, в каком месте списка стоят эти правила — в конце или в начале?
При твоей организации кэша этому комплексному правилу для правильной работы должно предшествовать правило, обрезающее номер порта. Убедись, что это так.
Сообщить модератору   Записан
tea
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 6
« Ответ #15 : 15 ноября 2007, 02:04:01 »
Накопилось немного статистики, поэтому…

Сейчас у меня появилось много дополнительных папок с именем «~».
Например: адрес «http://cоmmunity.lj.com/ru_jabber» сохраняется в папке «lj.com\community\~\ru_jabber\». Я так понимаю, что где-то остаётся лишний «слэш».
Оба правила, которые мне предложили, записаны как есть — подряд и стоят в конце списка «Преобразование URL».

Где и что мне исправить/добавить и т.п.?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #16 : 15 ноября 2007, 08:46:24 »
Цитата: tea от 15 ноября 2007, 02:04:01
Где и что мне исправить/добавить и т.п.?

Совсем забыл, что в версии 0.98b1 есть баг в работе опции "Заменить все" и в проверке необязательных правил... У меня-то в бета-версии оба правила работают как надо...

В общем, для совместимости с версией 0.98b1 замени 2-е правило на такое:

#5#~#True#~#//+#~#/#~#False#~#False
Сообщить модератору   Записан
Valeri614
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 5
« Ответ #17 : 25 августа 2008, 09:54:42 »
Цитата: DenZzz от 06 ноября 2007, 22:06:47
Вставь в "Преобразование URL" вместо того правила вот эти два подряд в указанном порядке:

#5#~#True#~#^(([^./]+)\.)?(([^./]+)\.)?(([^./]+)\.)?(([^./]+)\.)?([^./]+)\.([^./]+\.[^./\d]+)/#~#\10/\9/\8/\6/\4/\2/#~#False#~#True

#5#~#True#~#//+#~#/#~#False#~#False

Обрабатывает домены до 7-го уровня включительно. IP в URL не трогает.

всё замечательно работает!! Только как бы исключения сюда добавить, дабы, к примеру bash.org.ru складывался папку bash.org.ru, а не org.ru?
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #18 : 25 августа 2008, 12:06:37 »
Цитата: Valeri614 от 25 августа 2008, 09:54:42
Только как бы исключения сюда добавить

Проще всего через "Белый список".
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #19 : 25 октября 2009, 01:55:35 »
Всем привет.

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

Нынешняя структура кэша представляется мне неоптимальной. Я бы предпочел структуру вида:

Код:
http://www.ru-board.com/   -> d:\cache\ru-board.com\
http://forum.ru-board.com/ -> d:\cache\forum.ru-board.com\
заменить на такую:

Код:
http://ru-board.com/       -> d:\cache\com\ru-board\www\
http://forum.ru-board.com/ -> d:\cache\com\ru-board\forum\

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



Вопрос: возможно ли этого добиться штатными средствами HC?

А если нет, то не примет ли автор к рассмотрению?
« Последнее редактирование: 25 октября 2009, 01:59:42 от mirny » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #20 : 25 октября 2009, 02:35:22 »
Цитата: mirny от 25 октября 2009, 01:55:35
Вопрос: возможно ли этого добиться штатными средствами HC?

Да. Хоть правилами списка "Преобразование URL", хоть расширением.

Похожие темы:
http://handycache.ru/component/option,com_smf/Itemid,10/topic,980.0/
http://handycache.ru/component/option,com_smf/Itemid,10/topic,31.msg13549/#msg13549
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #21 : 25 октября 2009, 16:51:01 »
DenZzz, благодарствую.

Темы вкурил.

Отображение URL -> cache буду делать таким:
Код:
http://example.com/            -> d:\cache\com\e\example\www\
http://www.example.com/        -> d:\cache\com\e\example\www\
http://sub.example.com/        -> d:\cache\com\e\example\sub\
http://subsub.sub.example.com/ -> d:\cache\com\e\example\sub.subsub\
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #22 : 25 октября 2009, 20:01:08 »
Сделал такие два правила для списка "Преобразование URL":

#5#~#True#~#^((\w)[^./]*)\.([a-z]{2,4})/#~#\3/\2/\1/www/#~#False#~#True

#5#~#True#~#^(?>(?>www)\.)?((?>[^./]+))?\.((?>[^./]+)\.)?((?>[^./]+)\.)?((?>[^./]+)\.)?((?>[^./]+)\.)?((?>[^./]+)\.)?((\w)[^./]*)\.([a-z]{2,4})/#~#\9/\8/\7/\6\5\4\3\2\1/#~#False#~#True

Вроде бы все работает как задумано.

Осталось как-то сконвертировать существующий кэш.
« Последнее редактирование: 25 октября 2009, 20:25:03 от mirny » Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #23 : 25 октября 2009, 20:11:59 »
Цитата: mirny от 25 октября 2009, 20:01:08
Осталось как-то сконвертировать существующий кэш.

http://handycache.ru/component/option,com_smf/Itemid,10/topic,2608.0/

Только предварительно убедись в корректности предлагаемых преобразований.
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #24 : 26 октября 2009, 20:59:06 »
Почистил правила

#5#~#False#~#^(?>www\.)?((\w)[^./]*)\.([a-z]{2,4})/#~#\3/\2/\1/www/#~#False#~#True

#5#~#False#~#^(?>www\.)?([^./]+)?\.([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?((\w)[^./]*)\.([a-z]{2,4})/#~#\9/\8/\7/\6\5\4\3\2\1/#~#False#~#True

группу "(?>www\.)?" в начале оставил на всякий случай.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621
« Ответ #25 : 02 ноября 2009, 15:54:13 »
Цитировать
http://ru-board.com/       -> d:\cache\com\ru-board\www\
http://forum.ru-board.com/ -> d:\cache\com\ru-board\forum\

www вообще-то отбрасывается по умолчанию.

В какие папки сохранятся ссылки вида:
http://forum.ru-board.com/
http://ru-board.com/forum/

Обе в папку \cache\com\ru-board\forum ?


Добавлено: 02 Ноября 2009, 16:19:33

Спасибо огромное автору расширения MoveRename Files.
Правда после него остается мусор в виде лишних пустых папок, но их легко удалить.
Главное - теперь можно реализовать компактный режим кэша, о чем давно мечтал уже.

#5#~#True#~#^([^/]+\.)?((\w)[^./]*\.[^./\d]+(:\d+)?/)#~#\3/\2\0#~#False#~#True
#5#~#True#~#^\d+(\.\d+){3}(:\d+)?/#~#_IP/\0#~#False#~#True

http://forum.ru-board.com/ -> cache\r\ru-board.com\forum.ru-board.com\

на первом уровне каталогов - начальные буквы доменов второго уровня
на втором - сами эти домены
глубже - полные имена сайтов.

Теперь все разложено по полочкам и легко вычищать мусор из кэша Улыбка
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #26 : 03 ноября 2009, 03:21:01 »
Цитата: Сергей от 02 ноября 2009, 15:54:13
www вообще-то отбрасывается по умолчанию.
Здесь www добавлено чтобы уровень вложенности везде был одинаковым. Мне это нужно чтобы в любом случае можно было однозначно преобразовать путь обратно в урл.

Цитата: Сергей от 02 ноября 2009, 15:54:13
В какие папки сохранятся ссылки вида:
http://forum.ru-board.com/
http://ru-board.com/forum/

Обе в папку \cache\com\ru-board\forum ?
нет, в моей схеме будет так:
Код:
http://forum.ru-board.com/  -> d:\cache\com\r\ru-board\forum\
http://ru-board.com/forum/  -> d:\cache\com\r\ru-board\www\forum\

Цитата: Сергей от 02 ноября 2009, 15:54:13
http://forum.ru-board.com/ -> cache\r\ru-board.com\forum.ru-board.com\
наверно это хорошо визуально когда вы смотрите кэш в файловом менеджере, но избыточно и сильно удлиняет пути, которые у нас ограничены 200 знаками, насколько я понял. Все что превышает 200 знаков будет отрезано и заменено хэшем. Не означает ли это что в вашей структуре кэша таких обрезанных путей окажется больше?
Сообщить модератору   Записан
Ice
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 1
« Ответ #27 : 04 февраля 2010, 20:03:39 »
Есть просто мысль о небольшом улучшении удобства пользования Улыбка
В папке Cache хранить каталоги с именами доменов только задом наперёд Улыбка
Сейчас файл хранится по такому пути:
Код:
...HandyCache/Cache/releases.ubuntu.com/include/ubuntu.css
А сделать чтобы хранился по такому пути:
Код:
...HandyCache/Cache/com.ubuntu.releases/include/ubuntu.css
Т.е. просто сначала домен первого уровня, точка, домен второго уровня, точка, ... и т.д. все поддомены через точку Улыбка
Тогда все каталоги упорядочаться в папке Cache по имени и будет удобно что-то искать... Улыбка
Интересно, кто-нить ещё задумывался про такое? Улыбка
Скажем, чтобы не портить пользователям уже существующие кэши, то можно такое нововведение сделать через галочку. Кто поставил её, тому нате доменные имена наоборот Улыбка
Спасибо
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #28 : 05 февраля 2010, 11:34:21 »
Цитата: Ice от 04 февраля 2010, 20:03:39
Интересно, кто-нить ещё задумывался про такое?

И не просто задумывались, а уже есть несколько вариантов практического использования разных структур кэша! И ты вполне можешь сам реализовать свой! Никакой новой "галочки" в HC не понадобится. Надо всего лишь добавить твое правило в список "Преобразование URL".

Варианты таких правил описаны здесь:
http://handycache.ru/component/option,com_smf/Itemid,10/topic,980.0/
http://handycache.ru/component/option,com_smf/Itemid,10/topic,31.msg13549/#msg13549
« Последнее редактирование: 05 февраля 2010, 11:46:13 от DenZzz » Сообщить модератору   Записан
a.zhdanov
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 2
« Ответ #29 : 19 октября 2010, 00:04:43 »
А нельзя сделать, чтоб допустим весь яндекс находился в одной папке, допустим гугл тоже в своей папке, я просто пытался своими кривыми руками одноклассников запихать в одно место, но не выходит ни чего, правила которые здесь нашёл - поставил, но что-то видать не так
Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349
« Ответ #30 : 02 марта 2011, 00:55:09 »
Цитата: a.zhdanov от 19 октября 2010, 00:04:43
А нельзя сделать, чтоб допустим весь яндекс находился в одной папке, допустим гугл тоже в своей папке
Можно, конечно! У меня структура кэша определяется следующими тремя правилами списка "Преобразование URL":

#5#~#True#~#^((\d+\.){3}\d+)(/|$)#~#_IP-адреса_/\1/#~#False#~#True
#5#~#True#~#^([\w\d\-]+)\.([\w]+)(:\d+)?(/|$)#~#\1..\2/_NULL_/#~#False#~#True
#5#~#True#~#^([\w\d\-\.]+)\.([\w\d\-]+)\.([\w]+)(:\d+)?(/|$)#~#\2..\3/\1/#~#False#~#True

Весьма удобно: в папке ru-board..com, к примеру, будут подпапки forum и _NULL_. В папку _NULL_, которая в списке папок будет всегда на самом верху, кладется содержимое собственно сайта http://ru-board.com, а в папку forum - сайта http://forum.ru-board.com. IP-адреса сохраняются в отдельную папку специально для них, которую легко просматривать и чистить. Две точки вместо одной изначально были введены для программы HC Historian, чтобы избежать двусмысленности при восстановлении URL из пути к файлу в кэше. Если не пользуешься Историком - можно оставить только одну точку.
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #31 : 03 марта 2011, 03:23:57 »
помнится я вдохновлялся вашими идеями придумывая себе устройство кэша )
вместо двух точек взял обратный порядок т.е. somesite.com -> com.somesite , а вместо _NULL_ — www
Сообщить модератору   Записан
a.zhdanov
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 2
« Ответ #32 : 04 марта 2011, 20:56:48 »
Цитата: popkov от 02 марта 2011, 00:55:09
Можно, конечно! У меня структура кэша определяется следующими тремя правилами списка "Преобразование URL":

#5#~#True#~#^((\d+\.){3}\d+)(/|$)#~#_IP-адреса_/\1/#~#False#~#True
#5#~#True#~#^([\w\d\-]+)\.([\w]+)(:\d+)?(/|$)#~#\1..\2/_NULL_/#~#False#~#True
#5#~#True#~#^([\w\d\-\.]+)\.([\w\d\-]+)\.([\w]+)(:\d+)?(/|$)#~#\2..\3/\1/#~#False#~#True

Весьма удобно: в папке ru-board..com, к примеру, будут подпапки forum и _NULL_. В папку _NULL_, которая в списке папок будет всегда на самом верху, кладется содержимое собственно сайта http://ru-board.com, а в папку forum - сайта http://forum.ru-board.com. IP-адреса сохраняются в отдельную папку специально для них, которую легко просматривать и чистить. Две точки вместо одной изначально были введены для программы HC Historian, чтобы избежать двусмысленности при восстановлении URL из пути к файлу в кэше. Если не пользуешься Историком - можно оставить только одну точку.
Отлично! Спасибо! Теперь всё как я хотел Веселый
Сообщить модератору   Записан
Ontario
Новичок
*

Репутация: +0/-0
Offline Offline

Сообщений: 3
« Ответ #33 : 06 мая 2011, 07:03:47 »
Цитата: mirny от 26 октября 2009, 20:59:06
Почистил правила

#5#~#False#~#^(?>www\.)?((\w)[^./]*)\.([a-z]{2,4})/#~#\3/\2/\1/www/#~#False#~#True

#5#~#False#~#^(?>www\.)?([^./]+)?\.([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?((\w)[^./]*)\.([a-z]{2,4})/#~#\9/\8/\7/\6\5\4\3\2\1/#~#False#~#True

группу "(?>www\.)?" в начале оставил на всякий случай.


попробывал структуру кэша от mirny, вроде нормально
можно эти правила оптимизировать или оставить так?
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #34 : 06 мая 2011, 17:39:34 »
Вот что у меня сейчас стоит:

Код:
#5#~#True#~#^(([0-9a-z])[^./]*)\.([a-z]{2,4})/(?!\#-[0-9a-z]/)#~#\3/#-\2/\1/www/#~#False#~#True
#5#~#True#~#^([^./]+)\.([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?(([0-9a-z])[^./]*)\.([a-z]{2,4})/#~#\9/#-\8/\7/\6\5\4\3\2\1/#~#False#~#True
#5#~#True#~#^([a-z]{2})/\#-[0-9a-z]/(com?|net|org|biz|edu|gov|me|ac|pp|int?|ltd|plc)/(?!www/)(([0-9a-z])[^/.]*)/#~#\1.\2/#-\4/\3/www/#~#False#~#True
#5#~#True#~#^([a-z]{2})/\#-[0-9a-z]/(com?|net|org|biz|edu|gov|me|ac|pp|int?|ltd|plc)/(([0-9a-z])[^/.]*)\.([^/]+)/#~#\1.\2/#-\4/\3/\5/#~#False#~#True
Два последних правила необязательны, они мне нужны для того чтобы обрабатывать домены типа somesite.org.ru Вся эта группа правил должна стоять в конце списка.


Следующие три правила полезно добавить в начало списка:

Код:
#5#~#True#~#^[^:/@]+:[^:/@]+@(www\.)?(?=[^/]+/)(?# login:pass@example.com -> example.com)#~##~#False#~#True
#5#~#True#~#^([^:/]+):\d+/(?# example.com:8080 -> example.com)#~#\1/#~#False#~#True
#5#~#True#~#^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})/(?# 123.123.123.123 -> 123-123-123-123.ip)#~#\1-\2-\3-\4.ip/#~#False#~#True

Все правила отлажены и работают. Впрочем если б я все это сейчас делал, то уменьшил бы вложенность.
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #35 : 08 мая 2011, 16:11:53 »


Модифицировал структуру из своего предыдущего поста так, как мне давно хотелось. В правила добавлены комментарии. На пикче показано отображение адресов: mail.google.com; google.com; bash.org.ru

Желающие могут тестить.

Код:
True#~#^([^./]*)\.([a-z]{2,4})/(?# somesite.com/ -> com.somesite/www/)#~#\2.\1/www/#~#False#~#True
True#~#^([^./]+)\.([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]+\.)?([^./]*)\.([a-z]{2,4})/(?# sub7.sub6.sub5.sub4.sub3.sub2.sub1.somesite.com/ -> com.somesite/sub1.sub2.sub3.sub4.sub5.sub6.sub7/)#~#\9.\8/\7\6\5\4\3\2\1/#~#False#~#True
True#~#^([a-z]{2}\.)(com?|net|org|biz|edu|gov|me|ac|pp|int?|ltd|plc)/(?!www/)([^/.]*)/(?# uk.co/somesite/ -> uk.co.somesite/www/)#~#\1\2.\3/www/#~#False#~#True
True#~#^([a-z]{2}\.)(com?|net|org|biz|edu|gov|me|ac|pp|int?|ltd|plc)/([^/.]*)\.([^/]+)/(?# uk.co/somesite.sub1.sub2.sub3.sub4.sub5.sub6/ -> uk.co.somesite/sub1.sub2.sub3.sub4.sub5.sub6/)#~#\1\2.\3/\4/#~#False#~#True
« Последнее редактирование: 08 мая 2011, 16:27:44 от mirny » Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #36 : 30 мая 2011, 01:37:58 »
Тип файла я бы писал не в тело документа, как это делается сейчас, а прибавлял к названию файла в кэше.

Как-то так, например:

Код:
http://somesite.com/xmldoc.php  -> somesite.com\xmldoc.php#.xml
http://somesite.com/picture.php -> somesite.com\picture.php#.jpg
http://somesite.com/            -> somesite.com\#.html

В чем профит:
- новый список «не обновлять» станет проще
- файлы из кэша легче открывать, когда они с правильным расширением
- ХЦ в автономном режиме сможет отдавать правильные заголовки, ориентируясь на расширение файла в кэше
- ????
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #37 : 30 мая 2011, 09:22:06 »
Цитата: mirny от 30 мая 2011, 01:37:58
Тип файла я бы писал не в тело документа, как это делается сейчас, а прибавлял к названию файла в кэше.

А название кодировки HTML куда девать? Она тоже в файл пишется.

Цитировать
- новый список «не обновлять» станет проще

Не станет. Список «Не обновлять» работает по исходным URL, а не по преобразованным.

Кроме того, для HC уже есть расширения из группы «Не обновлять...», которые работают по типам файлов,  невзирая на URL.

Цитировать
- файлы из кэша легче открывать, когда они с правильным расширением

Кому легче? Пользователю?
HC станет намного сложнее, т.к. в момент запроса определить точное имя файла будет невозможно. Придётся перебирать все возможные варианты, что отнимет время и нагрузит диск лишней работой!

Цитировать
- ХЦ в автономном режиме сможет отдавать правильные заголовки, ориентируясь на расширение файла в кэше

Он и сейчас это хорошо умеет, ориентируясь на сигнатуры файлов и те подсказки, которые сам себе оставил.


P.S. При желании, можешь сам написать расширение, которое будет делать то, что ты предлагаешь. Но сразу предупреждаю, что работа НС значительно замедлится!
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #38 : 30 мая 2011, 13:18:32 »
>А название кодировки HTML куда девать? Она тоже в файл пишется.

Код:
<head>
<!-- text/html; charset=windows-1251 from header (HC) -->
<meta http-equiv="Content-Type" content="text/html; charset=windows-1251" />

Писать кодировку в файл вообще не нужно, ящитаю (в нынешнем виде уж точно, см пример выше — код взят из этой самой страницы в кэше), а то и вредно, если это файл css или xml — они от этого ломаются. Как вариант можно конвертить все в utf-8 либо вписывать кодировку правильно, что сложнее.

Сейчас ухожу, как вернусь — допишу по другим пунктам.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #39 : 30 мая 2011, 14:20:13 »
Цитата: mirny от 30 мая 2011, 13:18:32
Писать кодировку в файл вообще не нужно, ящитаю (в нынешнем виде уж точно, см пример выше — код взят из этой самой страницы в кэше),

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

Писать в HTML свою строку с Content-Type HC стал не сразу и не от хорошей жизни. Много проблем было до этого решения...

Цитировать
а то и вредно, если это файл css или xml — они от этого ломаются.

А в эти файлы свою строку никто и не пишет! Если у тебя есть конкретные примеры, то это баг. Дай ссылку - будем исправлять.

Цитировать
Как вариант можно конвертить все в utf-8

Плохой вариант, начиная от лишней работы и кончая размером файла на диске.

Цитировать
либо вписывать кодировку правильно, что сложнее.

Раньше так и было, но были проблемы, пришлось отказаться. HC стал дописывать в HTML свою строку в виде комментария.
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #40 : 30 мая 2011, 18:47:39 »
Если очень хочется куда-то эту кодировку записать, можно создавать файлик meta.txt в корне каждого хоста и вписывать ее туда. Кодировка в пределах сайта одна и таже же, кроме случаев лютой патологии.

Вообще можно всякого туда понавписывать. Реальный адрес хоста, например (с www. или без); номер порта, если нестандартный; логин:пароль@ тоже лучше туда чем в названии папки.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #41 : 30 мая 2011, 22:59:13 »
Цитата: mirny от 30 мая 2011, 18:47:39
Если очень хочется куда-то эту кодировку записать

Это не прихоть, а реальная необходимость, подкрепленная многолетним опытом!

Цитировать
можно создавать файлик meta.txt в корне каждого хоста и вписывать ее туда.

Уже обсуждалось ранее, но это увеличит количество дисковых операций и, следовательно, замедлит работу HC.
Решили, что оптимальнее будет прикрутить к HC базу данных SQLite для хранения мета-данных, но это пока не реализовано...

Цитировать
логин:пароль@ тоже лучше туда чем в названии папки.

логин:пароль@ в URL HTTP запроса быть и не может! См. RFC 2616.


P.S. Но хранение кодировки это вовсе не единственное "слабое место" в твоем предложении! Остальные перечисленные проблемы как решать предлагаешь?
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #42 : 31 мая 2011, 01:17:02 »
>Но хранение кодировки это вовсе не единственное "слабое место" в твоем предложении!

>HC станет намного сложнее, т.к. в момент запроса определить точное имя файла будет невозможно. Придётся перебирать все возможные варианты, что отнимет время и нагрузит диск лишней работой!

Ты так уверенно говоришь, что я чуть тебе не поверил. Это просто вопрос реализации, а не слабое место.

Рассмотрим пример для наглядности:

Случаев когда адрес оканчивается на / а там лежит не html исчезающе мало, поэтому предположить что файл в кэше будет называться #.html достаточно безопасно. Если произошла ошибка, срабатывает обработка исключений. И тогда действительно «Придётся перебирать все возможные варианты, что отнимет время и нагрузит диск лишней работой!» В исключительном случае.


>логин:пароль@ в URL HTTP запроса быть и не может! См. RFC 2616.

в RFC может быть и не может, а в HC мне когда-то для такого случая правило пришлось писать

#5#~#True#~#^[^:/@]+:[^/@]+@(www\.)?(?=[^/]+/)(?# login:pass@example.com -> example.com)#~##~#False#~#True
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #43 : 31 мая 2011, 09:37:39 »
Цитата: mirny от 31 мая 2011, 01:17:02
Случаев когда адрес оканчивается на / а там лежит не html исчезающе мало, поэтому предположить что файл в кэше будет называться #.html достаточно безопасно. Если произошла ошибка, срабатывает обработка исключений. И тогда действительно «Придётся перебирать все возможные варианты, что отнимет время и нагрузит диск лишней работой!» В исключительном случае.

Ты специально выбрал самый простой вариант? А если адрес заканчивается не на "/", а на ".php", ".cgi", "abcde?p=1" и т.п. Content-Type может быть любой. Будешь перебирать каждый раз все варианты? Это частый случай, а не исключительный!

Цитировать
в RFC может быть и не может, а в HC мне когда-то для такого случая правило пришлось писать
#5#~#True#~#^[^:/@]+:[^/@]+@(www\.)?(?=[^/]+/)(?# login:pass@example.com -> example.com)#~##~#False#~#True

Написать-то можно все, что угодно. Это не значит, что оно будет работать!
А реальность такова, что в HTTP-запросе не может быть никаких "логин:пароль@". Даже браузер такой URL не понимает!
Если же ты имел в виду FTP-запрос, то твое правило и на нем не будет работать. Проверь в тренажере...
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #44 : 31 мая 2011, 10:56:16 »
>Ты специально выбрал самый простой вариант?

Дело не в варианте, а в паттерне.

Код:
try:
    Берем самый ожидаемый Content-Type
except NoSuchFile:
    Не вышло, смотрим внутрь папки
   

Кстати вас ист «перебирать каждый раз все варианты»? Разве функция подобная glob() не существует в Делфи?

>Написать-то можно все, что угодно. Это не значит, что оно будет работать!

Это правило писалось для админки одного старого сайта. Таки работало. И в тренажере и на сайте.


>>ХЦ в автономном режиме сможет отдавать правильные заголовки, ориентируясь на расширение файла в кэше
>Он и сейчас это хорошо умеет, ориентируясь на сигнатуры файлов и те подсказки, которые сам себе оставил.

Умеет, но таки не очень хорошо. И txt и xml для него на одно лицо, выдает в виде хтмля.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #45 : 31 мая 2011, 14:04:58 »
Цитата: mirny от 31 мая 2011, 10:56:16
Кстати вас ист «перебирать каждый раз все варианты»? Разве функция подобная glob() не существует в Делфи?

Существует, но она и работает именно перебором всех файлов в директории, собственно также, как и glob() работает с помощью os.listdir(). И в Lua есть подобная функция lfs.dir().
Но работают они очень медленно, особенно когда в директории тысячи файлов, что совсем не редкость!

Цитировать
Это правило писалось для админки одного старого сайта. Таки работало. И в тренажере и на сайте.

Не знаю, где там у тебя работало, но ни один браузер в таком виде HTTP-запрос не пропустит! Если настаиваешь, то давай реальный рабочий пример.
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #46 : 31 мая 2011, 20:45:32 »
>Но работают они очень медленно, особенно когда в директории тысячи файлов, что совсем не редкость!

С этим можно справиться. Offline Explorer тому пример — по достижении тысячи файлов в папке начинает распихивать содержимое по служебным подпапкам.

>ни один браузер в таком виде HTTP-запрос не пропустит! Если настаиваешь, то давай реальный рабочий пример.

Не настаиваю. Давно было. Может и впрямь теперь по-другому.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #47 : 31 мая 2011, 22:31:21 »
Цитата: mirny от 31 мая 2011, 20:45:32
С этим можно справиться. Offline Explorer тому пример — по достижении тысячи файлов в папке начинает распихивать содержимое по служебным подпапкам.

Все равно такой кэш будет работать в разы медленнее, чем сейчас! Это не приемлемо.
Да и польза от такой структуры кэша спорна. Нерешенных проблем всплывает гораздо больше...
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #48 : 31 мая 2011, 22:55:56 »
>Все равно такой кэш будет работать в разы медленнее, чем сейчас!

Вовсе не факт. Замедление проявляется, только в случае, когда мы не угадали тип файла. Думаю реально, собрав статистику, подключив к алгоритму эвристику текущий список не обновлять, лол. Дотвикать процент промахов до приемлемого уровня.

Сравним с тем, что имеем сейчас:

  • если этот файл — html, то в него можно вписать, что он html (Великолепно, Кэп!)
  • если это не html, то мы SOSNOOLEY
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #49 : 01 июня 2011, 13:29:52 »
Цитата: mirny от 31 мая 2011, 22:55:56
Вовсе не факт. Замедление проявляется, только в случае, когда мы не угадали тип файла.

А гадать придется довольно часто! Допустим, зашли на новую страницу, ее файлов в кэше еще нет, но мы об этом не знаем. Что будем делать? Предположим, что это HTML. Проверили, файл на диске не найден. Что дальше? Продолжим предполагать: а вдруг это картинка JPG, а вдруг это картинка GIF, а вдруг это картинка TIF, а вдруг это флэш SWF, а вдруг это видео FLV и т.д. и т.п.? Будем перебирать все варианты? Их же десятки! И так с каждым новым файлом! Вот тебе и замедление в разы на ровном месте!

Цитировать
Думаю реально, собрав статистику, подключив к алгоритму эвристику текущий список не обновлять, лол. Дотвикать процент промахов до приемлемого уровня.

Не реально! И эвристика в случае выше не поможет. Все равно придется перебирать все варианты, чтобы не пропустить тот единственно верный.

Кстати, ты почему-то проигнорировал мою фразу, что список «Не обновлять» работает по исходным URL, а не по преобразованным. По путям и именам файлов в кэше он не работает! Или ты предлагаешь переделать логику работы списка "Не обновлять". Тогда практически всем пользователям придется корректировать свои правила в списке, да и работа самого списка существенно замедлится. Думаю, автор HC никогда на это не пойдет.

Цитировать
Сравним с тем, что имеем сейчас:

  • если этот файл — html, то в него можно вписать, что он html (Великолепно, Кэп!)
  • если это не html, то мы SOSNOOLEY

Тут ты не прав! Помимо HTML, HC прекрасно определяет типы и других файлов по сигнатурам. К примеру, картинки и видео. Некоторые файлы определяются по расширению, когда оно есть. А с остальными файлами прекрасно разбирается сам браузер! Уже и не помню, когда у меня были проблемы в браузере из-за работы HC в автономном режиме.

Тогда ради чего весь этот сыр-бор? Чтобы тебе было удобно вручную ковыряться в кэше? И ради этого придется решать кучу новых проблем:
- новый способ хранение кодировок HTML;
- изменение логики работы списка "Не обновлять";
- новый эвристический алгоритм угадывания имен файлов;
- существенное замедление работы HC с кэшем и увеличение нагрузки на диск.

Если у тебя сейчас есть реальные проблемы с определением типа файлов в автономном режиме HC, то давай конкретные ссылки. Подумаем, как решить эти проблемы с наименьшими потерями. Если ссылок таких нет и это лишь твое "хотение", то никто не мешает тебе реализовать его отдельным расширением. Все необходимое для этого в инструментарии HC уже есть...
« Последнее редактирование: 01 июня 2011, 13:57:13 от DenZzz » Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #50 : 02 июня 2011, 01:51:34 »
>Допустим, зашли на новую страницу, ее файлов в кэше еще нет, но мы об этом не знаем. Что будем делать?

Очевидно, что перебирать вслепую кучу вариантов в надежде найти страницу, которой может вообще не быть — негодная идея. Если смотреть в папку тоже нельзя, ибо медленно, на ум пока приходит только одно — ставить указатель с хедером (как это делается в случае редиректа).

Код:
http://somesite.com/xmldoc/  ->  somesite.com\xmldoc\#m
                                 somesite.com\xmldoc\#.xml

Что получается:

предположили #.html
    нет такого файла
обратились к #m
    PROFIT
#m тоже отсутствует
    тогда мы знаем, что такой страницы в кэше нет
   
   
и, разумеется, для случая \htmldoc\#.html указателя ставить не надо, ибо там не ошибешься.


>Тогда ради чего весь этот сыр-бор?

Просто нашел хороший проксик на питоне и теперь руки чешутся запилить всякие ништяки на его основе, которые я врятли увижу в HC. Пока определяюсь какие именно и стОит ли.
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589
« Ответ #51 : 02 июня 2011, 10:36:13 »
Цитата: mirny от 02 июня 2011, 01:51:34
Просто нашел хороший проксик на питоне и теперь руки чешутся запилить всякие ништяки на его основе, которые я врятли увижу в HC.

Можешь запилить эти ништяки на НС. Все для этого есть...
Сообщить модератору   Записан
mirny
Пользователь
**

Репутация: +11/-1
Offline Offline

Сообщений: 84
« Ответ #52 : 02 июня 2011, 20:40:12 »
>Можешь запилить эти ништяки на НС. Все для этого есть...

OK. Пошел разбираться...
Сообщить модератору   Записан
Страниц: 1 2 3 [Все]   Вверх
  Отправить эту тему    Печать  

« предыдущая тема следующая тема »
 
Перейти в:  



Powered by SMF 1.1.3 SMF © 2006, Simple Machines LLC
Joomla Bridge by JoomlaHacks.com