» HandyCache ( Часть 4 )

rs
forever
спасибо, что прекратили...
на последних страницах от силы 5 постов по теме, остальное ваше...
можно попросить вас обсуждать это не здесь? если не хотите в ПМ, заведите отдельную тему во флейме, там это в самый раз.

что касается win9х, внесу свои 2 копейки: я не считаю, что имеет смысл делать программу, оглядываясь на ОС, вышедшую 9 лет назад и ныне не поддерживаемую даже производителем. Такая "обратная совместимость" только тянет назад, мы ограничиваем себя функциональностью устаревшей ОС, и ради чего? Есть линейка NT, которая сама по себе лучше + развивается и поддерживается, давайте на это и ориентироваться. Если кто-то не может позволить себе поставить на машину winXP - это по моему глубокому убеждению его личные проблемы, и не надо ради таких пользователей тянуть программу назад.

forever
мне было бы стыдно называть чужое мнение бредом

pop2ROOT

Цитата:

спасибо, что прекратили...

Как знать. Вдруг таки родит rs чтонить в ночь?


Цитата:

заведите отдельную тему во флейме, там это в самый раз.

В общем-то да, рационального в этой беседе уже ничего нет. Одно НО: если ему упрямство не позволяет признать несостоятельность затеи - вдруг действительно сделает? Так же просто из упрямства?


Цитата:

что касается win9х, внесу свои 2 копейки: я не считаю, что имеет смысл делать программу, оглядываясь на ОС, вышедшую 9 лет назад и ныне не поддерживаемую даже производителем.

1. Тем не менее эта система по сей день используется.
2. В данном вопросе речь вовсе не ОС - о файловой системе. FAT32 очень даже распространен.
3. И даже не в файловой системе дело - в ненужной затее. Никому не нужной. На любой оси и любой FS.

rs

Цитата:

мне было бы стыдно называть чужое мнение бредом

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

forever
FAT32 уже недолго осталось - при нынешних-то объемах винтов + виста...
можно начинать прощаться.
а нужность затеи - это другой вопрос. имхо потоки для того и созданы, чтобы в них доп.инфу сохранять, так почему бы этим не пользоваться?

pop2ROOT

Цитата:

FAT32 уже недолго осталось - при нынешних-то объемах винтов + виста...

Им пользуются - это нужно учитывать. А не диктовать юзерам какую файловую систему они должны иметь.


Цитата:

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

Это напоминает старую шутку фармацевтов: придумали лекарство - теперь бы придумать болезнь, которую оно лечит.
Если нет надобности в использовании потоков - зачем пыжиться и выдумывать что б такого в них запихнуть?

pop2ROOT

Цитата:

Такая "обратная совместимость" только тянет назад, мы ограничиваем себя функциональностью устаревшей ОС, и ради чего?

Когда есть альтернативный способ реализовать новую фичу, сохранив при этом совместимость с Win9x/Me, - это надо делать!

Цитата:

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

Про ограничения этого метода много было сказано! Не стоит повторяться...

forever

Цитата:

1. Тем не менее эта система по сей день используется.

Некоторые еще и DOS использует. Под них тоже подстраиваться?
Если система не тянет WinXP, пускай ставят Win2000. У меня до недавнего времени как раз и стояли Win98+Win2K одновременно.

Цитата:

Им пользуются - это нужно учитывать. А не диктовать юзерам какую файловую систему они должны иметь.

Если система не ниже win2K, то никто не мешает создать два раздела: FAT32 и NTFS (специально для кэша HC). А если 98-я, то прочитай абзац выше.

DenZzz

Цитата:

Про ограничения этого метода много было сказано!

И какие-такие ограничения? AVP отметается, т.к. он этому не мешает.

unreal666

Цитата:

И какие-такие ограничения? AVP отметается, т.к. он этому не мешает.

Лыко-мочало... Прочти здесь и соседние страницы, если позабыл! Там:
- и о совместимости с не NTFS-системами,
- и о хранении кэша на сервере в локалке или флешке,
- и о трудностях переноса потоков на другой комп,
- и о лишней нагрузке на винт при чтении парных потоков (в сравнении однократным чтением индексов) и т.д. ...

DenZzz

Цитата:

- и о совместимости с не NTFS-системами,

Мой довод я уже написал:

Цитата:

Если система не тянет WinXP, пускай ставят Win2000. У меня до недавнего времени как раз и стояли Win98+Win2K одновременно.

Кому не нравится , пускай используют вариант с индексами. Мне, например, лишние индексы в кэше не нужны.

Цитата:

- и о хранении кэша на сервере в локалке или флешке,

Пускай используют вариант с индексами.

Цитата:

- и о трудностях переноса потоков на другой комп,

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

Цитата:

- и о лишней нагрузке на винт при чтении парных потоков (в сравнении однократным чтением индексов) и т.д. ...

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

Подскажите как в условных прокси прописывать условия выбора внешнего прокси в зависимости от пользователя HC?

Visman
Никак. Условия задаются только в зависимости от URL.

unreal666

Цитата:

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

С того перепугу, что индексы не обязательно скидывать на диск после каждого сохранения файла в кэш! Все операции можно производить в памяти - это намного быстрее дисковых операций и съест не так уж много памяти, если не хранить в индексе всякий лишний мусор.
Кроме того, ускорится работа HC c дисковым кэшем, т.к. не надо будет постоянно обращаться к диску для выяснения, есть ли там файл и какая у него дата (для списков "Не обновлять" и "Только из кэша", проверки "свежести" и формирования заголовка "If-Modified-Since").

Только не говори, что у тебя в памяти каждый килобайт на счету... Твои постоянные чтения парных потоков съедят не меньше системных ресурсов!

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

Чтобы отсечь прочие повторные вопросы, прочти это! Там собрано большинство уже обсужденных идей по индексам...

Цитата:

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

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

Цитата:

если не хранить в индексе всякий лишний мусор.

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

Цитата:

Кроме того, ускорится работа HC c дисковым кэшем, т.к. не надо будет постоянно обращаться к диску для выяснения, есть ли там файл и какая у него дата

А если во время работы HC я произвел чистку кэша? Что тогда?

Цитата:

Только не говори, что у тебя в памяти каждый килобайт на счету... Твои постоянные чтения парных потоков съедят не меньше системных ресурсов!

Не килобайт, а сотни килобайт. Может даже и мегабайты (в зависимости от размера кэша и от того, что вообще хранится в индексе).

Цитата:

Твои постоянные чтения парных потоков съедят не меньше системных ресурсов!

Для NTFS чтение содержимого файла и чтение потока не отличаются. так что никаких дополнительных ресурсов съедаться не будет.

Цитата:

можно сделать по индексу на папку сайта (хост) и подгружать их по мере надобности

Как я уже писал, мне не нужны лишние файлы в кэше (занимают место, да и мешаются). Да и они случайно тоже могут попасть под чистку кэша.

-------
Пока писал кое-что дошло. Если делать то через индексные файлы, то как из этих индексов убирать лишнее после чистки кэша?

unreal666

Цитата:

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

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

Цитата:

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

Я уже отвечал на этот вопрос здесь. Мусор - это инфа, без которой HC может обойтись: пользователей пусть хранит "Историк", "Content-Type" не нужен для известных форматов, даты доступа хватит одной на каталог и т.д.
Вопрос, скорее, не что хранить, а для чего хранить лишнее!? Чем эта лишняя инфа может быть полезна HC в плане функциональности?!

Цитата:

А если во время работы HC я произвел чистку кэша? Что тогда?

HC инициирует по твоему запросу или сам, когда обнаружит рассинхронизацию, процедуру очистки индекса и удаляет из него инфу о файлах, которых уже нет в кэше. К слову, такая ситуация пока никак не отслеживается в RAM-кэше, но зато есть чудо кнопка "Очистить RAM-кэш"!

Цитата:

Не килобайт, а сотни килобайт. Может даже и мегабайты (в зависимости от размера кэша и от того, что вообще хранится в индексе).

Разве это много при современных размерах и ценах на RAM? Увеличить память проще, чем поменять весь компьютер с операционной системой, как предложил pop2ROOT...

Цитата:

Для NTFS чтение содержимого файла и чтение потока не отличаются. так что никаких дополнительных ресурсов съедаться не будет.

А теперь представь, что читать диск придется ДВАЖДЫ для КАЖДОГО файла: сами данные и поток. Вспомни, что диск - это очень медлительная "железяка" в сравнении с памятью. И делай вывод о времени, затраченном на обработку одного индекса либо кучи потоков... Не пугает?

Цитата:

Как я уже писал, мне не нужны лишние файлы в кэше (занимают место, да и мешаются).

По паре файлов на сайт (хост) - думаю переживешь...

Цитата:

Да и они случайно тоже могут попасть под чистку кэша.

Так случайно можно и винт форматнуть...

Цитата:

Пока писал кое-что дошло. Если делать то через индексные файлы, то как из этих индексов убирать лишнее после чистки кэша?

Читай ответ на третий вопрос.

Цитата:

Случайно можно и винт форматнуть...

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

Цитата:

По паре файлов на сайт (хост) - думаю переживешь...

Ага. У меня сейчас в кэше около 2000 сайтов, т.е. минимум будет 2000 индексных файлов. А если "По паре файлов на сайт", то 4000 файлов.
Это немного что ли?
4000 файлов на NTFS займут минимум 4 Мб.

Цитата:

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

Для этого надо сканировать весь кэш и сравнивать с соответствующими индексными файлами.

Цитата:

Вспомни, что диск - это очень медлительная "железяка" в сравнении с памятью.

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

unreal666

Цитата:

А вот всякие индексные файлы под чистку кэша могуь и попасть

Чисть так, чтобы не попали! В штатной "Очистке кэша" через HC это просто можно запретить!

Цитата:

4000 файлов на NTFS займут минимум 4 Мб.

Уууу... И с RAM у тебя напряженка и каждый Мб на многоГИГАбайтном винте на счету - срочно последуй совету pop2ROOT - меняй комп!!!

Можно подумать, потоки для КАЖДОГО файла вообще не на винте хранятся!
Умножь количество файлов в твоем кэше на 1кБ (предполагаемый размер потока) и приди в ужас...

Цитата:

Для этого надо сканировать весь кэш и сравнивать с соответствующими индексными файлами.

Не весь, а только конкретную рассинхронизированную папку (или несколько папок).

Цитата:

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

Ну, наконец-то, ты уже не отвергаешь хранение нужных атрибутов в памяти! Уже хорошо!
А теперь прикинь, для того чтобы засунуть всю эту "фигню" в память тебе придется прочесть на диске тысячи потоков, а мне пару индексов! Есть разница?

Задумал перейти с CoolProxy на HandyCache,
В описании к сабжу прочитал что можно подключить кеш от CP только в режиме чтения, означает ли это, что необходимо указать в настройках каталогов новый путь к собственно каталогу кеша HC а в каталоге для чтения путь к старому каталогу CP? Будет ли при этом при обращении к странице просматриваться оба каталога, и все обновления будут заноситься уже в каталог HC? И для чего предусмотрен второй список кеша?

Цитата:

И с RAM у тебя напряженка и каждый Мб на многоГИГАбайтном винте на счету - срочно последуй совету pop2ROOT - меняй комп!!!

У меня нет денег даже на замену материнки. Из-за одной дуры (пролива пепси на материнку - у меня системник все время открыт) перестал работать IDE-канал Secondary Master.

Цитата:

Умножь количество файлов в твоем кэше на 1кБ (предполагаемый размер потока) и приди в ужас...

С чего ты взял, что для потока создается отдельная MTF-запись? MFT-потоки хранятся в той же MTF-записи, что и сам файл (если помещаются там), т.к. поток - это атрибут файла.

Цитата:

Не весь, а только конкретную рассинхронизированную папку (или несколько папок).

Чтобы узнать что рассинхронизировано, надо просканировать весь кэш.

Цитата:

А теперь прикинь, для того чтобы засунуть всю эту "фигню" в память тебе придется прочесть на диске тысячи потоков, а мне пару индексов! Есть разница?

А я не говорю, что прочесть все потоки сразу. В памяти хранить те потоки, которые уже были прочитаны. Т.е. типа RAM-кэша при использовании файлов.

Пытаюсь зайти на страничку с расширением *.pl, handycache не пускает. Отключаю HandyCache - все нормально. Где подправить в настройках?

n2wz
Посмотри в мониторе, чего он там говорит насчет этого URL.
Монитор для того и дан.

unreal666

Цитата:

С чего ты взял, что для потока создается отдельная MTF-запись? MFT-потоки хранятся в той же MTF-записи, что и сам файл (если помещаются там), т.к. поток - это атрибут файла.

Вот именно "если помещаются там", а если нет - то используется еще одна MFT-запись размером в 1 кб. Кроме того, сами данные потока могут хранится за пределами MFT - в области данных, а в MFT же только описание занимаемых им кластеров.
А учитывая, что в MFT хранятся еще и: название файла (в Unicode), размер, даты, атрибуты безопасности, списки кластеров и т.д., то уместить все в одну MFT вряд ли удастся!

Цитата:

Чтобы узнать что рассинхронизировано, надо просканировать весь кэш.

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

Цитата:

А я не говорю, что прочесть все потоки сразу. В памяти хранить те потоки, которые уже были прочитаны. Т.е. типа RAM-кэша при использовании файлов.

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

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

Цитата:

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

Пока кэш не чистил. Но когда буду чистить, то буду чистить с помощью nnCron'а. У него больше возможностей для этого, чем у HC.
Так что этот вариант чистки не подпадает ни под 1-ый ни под 2-ой твои варианты.

Цитата:

А учитывая, что в MFT хранятся еще и: название файла (в Unicode), размер, даты, атрибуты безопасности, списки кластеров и т.д., то уместить все в одну MFT вряд ли удастся!

В MFT-запись помимо основных атрибутов помещается дополнительно 700 байт данных. А это по заглаза.

Цитата:

еще одна MFT-запись размером в 1 кб.

Обычно размер кластера в FAT32 не меньше 2 кбайт. А 1 кб < 2 кб.

DenZzz

Цитата:

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

с потоками даже таких небольших потерь не будет... и потом - кто знает - небольших ли?

как-то странно иметь систему, дпускающей иметь атрибуты клочьями - для этих файлов атрибуты есть, для этих - нет (потерялись)

зачем так изначально проектировать систему? потоки этого недостатка лишены также изначально

Добавлено:

Цитата:

даты доступа хватит одной на каталог и т.д.

- тоже не сильно прицельно как-то... плюс-минус лапоть

Добавлено:
DenZzz

Цитата:

Не весь, а только конкретную рассинхронизированную папку (или несколько папок).

чтобы обнаружить факт наступления рассинхронизации - нужно ВЫПОЛНЯТЬ этот контроль, т.е. читать время от времени (как часто?) ВСЕ(!) файлы в кэше, на предмет сверки с индексом... за что спрашивается боролись? - молотить винт время от времени ТОЛЬКО для уверенности в идексе - тому что индексу попросту можно ВЕРИТЬ...

Добавлено:
DenZzz

Цитата:

А теперь прикинь, для того чтобы засунуть всю эту "фигню" в память тебе придется прочесть на диске тысячи потоков, а мне пару индексов! Есть разница?

не тысячи - я в каждую секунду не обращаюсь ко всем файлам в кэше... одномоментно обрабатывается только оди н файл в кэше с его же потоком (со скоростью выплёвывания страниц из HC и попадания их в браузер) - затараты на работу с диском минимальны

mai62
Помнится, когда-то на предложение делать юникодовый билд, ты ответил,- что неплохо бы, но текущие проблемы весьма важные и их надо разводить в первую очередь. Сейчас, в свете того, что ты начинаешь реализацию плагинного API, может в самый раз вспомнить об этом?

Я за индексы или хотя бы контейнер для хранения типа файла для безымянных файлов, чтоб картинки без расширения не обновлялись. Использую FAT32.

unreal666

Цитата:

В MFT-запись помимо основных атрибутов помещается дополнительно 700 байт данных. А это по заглаза.

Не факт! Одно имя файла в Unicode занимает по 2 байта на букву, а там еще хранятся даты, список кластеров, атрибуты и т.д. Даже без потоков 1 записи может не хватить!

Цитата:

Обычно размер кластера в FAT32 не меньше 2 кбайт. А 1 кб < 2 кб.

Угу. Округлить тысячу раз до 1 кб или один раз до 2 кб. Есть разница?

rs

Цитата:

чтобы обнаружить факт наступления рассинхронизации - нужно ВЫПОЛНЯТЬ этот контроль, т.е. читать время от времени (как часто?) ВСЕ(!) файлы в кэше, на предмет сверки с индексом...

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

Цитата:

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

Ты нет, а вот SAI666 даже предлагал изменить порядок списков и добавить второй ЧС для ускорения работы с диском! С индексом всего этого "добра" не понадобится!

Цитата:

обрабатывается только один файл в кэше с его же потоком (со скоростью выплёвывания страниц из HC и попадания их в браузер) - затараты на работу с диском минимальны

Угу, и двойная нагрузка на диск - это вовсе не нагрузка...

---

Что вы опять заладили здесь про потоки... Mai62 сказал: "ПОТОКОВ НЕ БУДЕТ"!!!
Делайте потоки опцией в "Историке" и обсуждайте их "плюсы" в его ветке!
А время и практика покажет, кто был прав!!! Думаю, очень быстро покажет...

Цитата:

Mai62 сказал: "ПОТОКОВ НЕ БУДЕТ"!!!

Пускай сделает API и будут потоки.

DenZzz

Цитата:

Цитата:чтобы обнаружить факт наступления рассинхронизации - нужно ВЫПОЛНЯТЬ этот контроль, т.е. читать время от времени (как часто?) ВСЕ(!) файлы в кэше, на предмет сверки с индексом...

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

ты не понял - сама по себе рассинхронизация не выявится.. ты её должен СПЕЦИАЛЬНО выявлять, т.е. ПРЕДПРИНИМАТЬ некие действия (затратив ресурсы - процессорные, дисковые, которые твы кстати и хочешь сэкономить, а вынуждет тратить) - ведь не найдя файла в индексе (а в кэше на самом деле файл есть), HC понятия не имеет, что не нашёл файл в кэше лишь по причине кривизны индекса - он (HC) искренне считает, что файла нет в кэше, хотя его нет только в индексе... для того чтобы ЗАПОДОЗРИТЬ рассинхронизацию нужны предположения о рассинхронизации (откуда они возьмутся?) и ДЕЙСТВИЯ по ОБНАРУЖЕНИЮ рассинхрона... можно конечно что-то типа планировщика сделать, запусакющего тест синхронности индекса и кэша... но как-то это всё архитектурной косолапостью системы попахивает... подпорки на подпорках...


Цитата:

Ты нет, а вот SAI666 даже предлагал изменить порядок списков и добавить второй ЧС для ускорения работы с диском! С индексом всего этого "добра" не понадобится!

ты упускаешь 1)существенно более весомые затраты на ПОДДЕРЖАНИЕ синхронизации [см. в моём абзаце выше] и 2)достаточно высокую вероятность попасть в рассинхронизированное состояние индекса в интеравалах между процедурами контроля синхронизации. и поскольку, как ты сам согласился, потеря атрибутов индекса необратима (из файловкэша их взять уже нельзя) - то имеем ещё к первым двум пунктам ещё один смачный довесок минусов - 3)часть файлов в кэше могут иметь доп. атрибуты (не имели проблем с индексами), а другие в этом же кэше уже не имеют дп. атрибутов (потеряли индекс и не смогли их восстановить по кэшу) - "клочакстое" наполнение атрибутами файлов кэша.

всё это СЛИШКОМ серьёзные минусы, чтобы закладывать их в качестве архитектурного решения.

НИ ОДИН из ЭТИХ минусов не свойствен потокам в файлах кэша по определению... - следовательно для решения этих проблем можно ВООБЩЕ НИЧЕГО предпринимать - этих проблем просто НЕТ.


Цитата:

Угу, и двойная нагрузка на диск - это вовсе не нагрузка..

есть проги, типа filemon от sysinternals, кажется... - можешь посмотреть что ежесекундно происходит с диском - ты просто ужаснёшься - и своп и реестр и антивирус и... - в общем на фоне этого дискового общеситсемного беспредела всевозможных программ и програмулечек, пишущих и читающих диск - лишний один поток (крохотный поточек) на файл в кэше - это просто смешно... это даже не проценты, это доли процентов от объёма общесистемных файловых операций в течение того же времени, что и доступ к файлу кэша


Цитата:

Что вы опять заладили здесь про потоки... Mai62 сказал: "ПОТОКОВ НЕ БУДЕТ"!!!

такое впечатление, что ты услышал то, что тебе приятнее было бы слышать

он сказал лишь, что не хочет сейчас вступать в обсуждение... вероятно, не готов занять любую из позиций и что ntfs-потоки ему не очень нравятся... вполне разумно, в общем-то... а с чего ты вязл, что он под действием аргументов не изменит мнения c течением времени?



Цитата:

А время и практика покажет, кто был прав!!! Думаю, очень быстро покажет...

чудится мне, что решать будет всё же НЕ ВРЕМЯ, а ЛЮДИ с течением времени - разница всё ж есть...


а чтобы эти люди решили с течением времени - требуется ОБСУЖДЕНИЕ... из ничего (без обсуждения) архитектура не родится


unreal666

Цитата:

Пускай сделает API и будут потоки.

вот именно

rs

Цитата:

ведь не найдя файла в индексе (а в кэше на самом деле файл есть), HC понятия не имеет, что не нашёл файл в кэше лишь по причине кривизны индекса

Если файла нет в индексе, то HC просто скачает его с сервера и запишет в индекс! Никакой трагедии здесь нет!

Что ты заладил про рассинхронизацию? Это ФОРС-МАЖОР, а не нормальная работа! При граммотной настройке системы и HC, обычный пользователь с ней никогда не столкнется!
А если форс-мажор и случится, то пользователь или HC запустит процедуру синхронизации, как делает твой "Историк"!
Никакого расписания с постоянным мониторингом для нормальной работы просто НЕ ПОНАДОБИТСЯ!

Цитата:

1)существенно более весомые затраты на ПОДДЕРЖАНИЕ синхронизации [см. в моём абзаце выше]

Ничуть, твой форс-мажор в расчет не берем, как крайне редкое событие!

Цитата:

2)достаточно высокую вероятность попасть в рассинхронизированное состояние индекса в интеравалах между процедурами контроля синхронизации

См. ответ выше.

Цитата:

всё это СЛИШКОМ серьёзные минусы, чтобы закладывать их в качестве архитектурного решения.

Все это ФОБИИ отдельно взятого индивидуума, неумеющего настраивать систему, HC и работать с его кэшем! Из разряда: "А если Земля сойдет с небесной оси?"...

Цитата:

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

Ага, а потоки с подробными данными для уже существующего сейчас кэша ты из воздуха возьмешь?! Бредовый аргумент!

Цитата:

можешь посмотреть что ежесекундно происходит с диском - ты просто ужаснёшься - и своп и реестр и антивирус и...

А ты решил все это усугубить дополнительной нагрузкой на диск!? Отличный аргумент!
Лучше запусти свой антивирус на сканирование всех дисков и посмотри в отладочной информации HC, как в десятки раз возросло время чтения с диска, а из RAM-кэша - практически не изменилось!

Цитата:

он сказал лишь, что не хочет сейчас вступать в обсуждение...

Не пытайся читать между строк! Лучше прочти еще раз сам ответ...

Цитата:

а чтобы эти люди решили с течением времени - требуется ОБСУЖДЕНИЕ... из ничего (без обсуждения) архитектура не родится

Отлично! Идите в ветку "Историка" и рожайте! А сторонники индексов будут из далека радоваться вашим успехам!

P.S. Надоело спорить в десятый раз об одном и том же по кругу! Ушел спать...

А бывает ли у кого-нибудь такой глюк: запускаю Оперу, в этот момент к инету не подключен (автономный режим), открывается сразу 25 сайтов (мелкие картинки, смайлики и т.д.). И, в какой-то момент прекращается загрузка страниц, винт перестаёт шуметь, в мониторе ветки стоят. Решил включить лог поглядеть, пока винт шумел лог весело бежал, потом бац, всё останавливается, окно лога мелькает словно что-то меняется, но текст остаётся прежним. Правда иногда на пустую строку вверх уходит. Через некоторое время загрузка сама собой начинает продолжаться, но лог не двигается. Помогает, только если нажать клавишу отчистить лог, тогда снова всё приходит в норму.