Что про сабж, кстати, скажешь?

> Лично я не пользовался им и даже не тестировал. Во-первых, оверхэд при парсинге (и потребление ОЗУ, т.к. надо держать всю эху целиком, а не только индекс). Во-вторых, уже давно написаны ii-db-utils и IDEC-utils, которые совместимы только с "классикой".

Я бы не сказал, что такой уж оверхэв, бо держать в ОЗУ пару-тройку мегабайт и при этом не иметь почти 30к мелких файлов в одной директории это более правильно, чем держать маленький индекс в памяти и держать кучу файлов. В любом случае, если вдруг на машине не найдётся пары лишних мегабайт в ОЗУ, можно использовать и старый формат.

> Ошибкой считаю то, что ты сделал 2 отдельных мейлера-фетчера для новой базы. Лучше создать единый интерфейс и вынести все функции доступа к базам туда (указывать нужную исключительно в конфиге). Прикладные программы вроде фетчера и самого клиента вообще не должны иметь к базе никакого отношения.

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

Фетчер же я вынес сугубо для того, чтобы не дублировать функционал в отдельном фетчере при ноде и в клиенте.

AL> Я бы не сказал, что такой уж оверхэв, бо держать в ОЗУ пару-тройку мегабайт и при этом не иметь почти 30к мелких файлов в одной директории это более правильно, чем держать маленький индекс в памяти и держать кучу файлов. В любом случае, если вдруг на машине не найдётся пары лишних мегабайт в ОЗУ, можно использовать и старый формат.

Дело даже не столько в ОЗУ. Проблема в том, что на каждый чих это всё считывать и парсить. Как у нас обычно - на splitlines(). А это ещё и время.

sqlite - это хорошо, потому что там работа с одним файлом наиболее эффективно реализована. А ещё там есть индексация.

Доверять сабжу такие эхи, как lenta.rss или lor-opennet.15 я бы не стал.

AL> Вот спорный вопрос. В идеале тогда должно быть две программы: мейлер/фетчер и тоссер, но это мне не нравится.
AL> То есть я руководствуюсь тем, что каждая программа - это вещь в себе и ничего ей для работы больше не нужно. По крайней мере стремлюсь к этому.

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

Да и вся эта возня с "вещью в себе" порой превращает исходники в макаронные изделия.

Видимо, придётся мне всё-таки подробно почитать как описание бинарного формата sqlite, так и код реализацию aio.
Потестирую ещё потом, как будет время.

> Дело даже не столько в ОЗУ. Проблема в том, что на каждый чих это всё считывать и парсить. Как у нас обычно - на splitlines(). А это ещё и время.

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

> sqlite - это хорошо, потому что там работа с одним файлом наиболее эффективно реализована. А ещё там есть индексация.

> Доверять сабжу такие эхи, как lenta.rss или lor-opennet.15 я бы не стал.

Вот как раз такие пухлые эхи сильно тормозят sqlite и гораздо меньше тормозят aio. Я его потому и добавил в апстрим, что оно оказалось не так уж и плохо. И даже оперативнее СУБД.

> Как хочешь, но поддерживать это и по времени, и по силам сложнее. Ошибок проще наделать и так далее. Когда я в php-ноде реализовал систему транспортов, у меня голова меньше болеть стала по поводу разных кусков кода, реализующих по сути одно и то же.

> Да и вся эта возня с "вещью в себе" порой превращает исходники в макаронные изделия.

Вот с этим не поспоришь. Может, я и вынесу это всё в отдельную библиотеку со временем.