У вас совершенно явные проблемы с кешированием...

http://lib.rus.ec/node/73?
и
http://lib.rus.ec/node/73
Показывают разные страницы (во втором нету моего последнего комента)

Залогинился?

Кеширование работает для анонимов. А их - не жалко.

Кеширование работает для анонимов. А их - не жалко
Гхм... Николаю это странно... Сильно странно...

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

Друпал так устроет, и, думается в этом есть что-то разумное.
Для анонимов все страницы жестоко кэшируются и обновляются раз в как настроишь. Для уменьшения нагрузки на сервер.
Страдае от этого в основном форум, ну так там анонимам делать нечего - там ничего интересного для них нет, обсуждение сайта, не книг.
Текущий хостинг всем хорош, но в cpu-квоту я укладываюсь с трудом. Пока не переехал, стараюсь экономить. А то приходит бот и давай тянуть всё подряд - и привет, оверквота.
Автологин для OpenId починили в шестом друпале, обещают релиз через пару недель. Поэтому мне сейчас самому копаться неохота. Сходу не разобрался, вглубь не лез.
Такие дела.

Друпал так устроет... Для анонимов все страницы жестоко кэшируются и обновляются раз в как настроишь.
Гм... Я всегда не доверял людям которые пишут на PHP... Они используют какую-то альтернативную (по сравнению с моей) логику... ;-)

Я бы с удовольствием писал на перле. После перла от php подташнивает.
К сожалению, ни одной приличной cms на перле я не нашёл. А делать всё самому с нуля - некогда.
Так что имеем, что имеем.

А так согласен - выбрать php вместо перла можно только на базе альтернативной логики. Я никаких преимуществ не вижу, одни недостатки. Впрочем, по сравнению с xls или там шарпом - php вполне употребим.

Кстати, в рамках твоей логики, как решать следующую проблему
1. Страницы сайта генерятся тяжёлым скриптом неважноначём. Куча шаблонов, список посетителей, новости и т.п.
2. Приходит бот и тащит их со страшной силой (wget -m или гуглёбот какой. У меня боты жрут больше половины траффика.)
3. Процессора не хватает. Слабое место.
Чо делать-то?

К сожалению, ни одной приличной cms на перле я не нашёл. А делать всё самому с нуля - некогда.
Я использую Коммунивер
http://www.communiware.ru/cmw_platform
http://www.communiware.org
http://cmw-cms.ru/
Там вообщем полным полно проблем. Но проектировали эту систему люди знакомые с теорией множеств, и программированием одновременно. Потому работать с ней крайне приянто.

Кстати, в рамках твоей логики, как решать следующую проблему
1. Страницы сайта генерятся тяжёлым скриптом неважноначём. Куча шаблонов, список посетителей, новости и т.п.
2. Приходит бот и тащит их со страшной силой (wget -m или гуглёбот какой. У меня боты жрут больше половины траффика.)
3. Процессора не хватает. Слабое место.
Чо делать-то?

Ну вопервых, если html из fb2 гененриться динамически, немедленно сделать статическим. Именно так это сделано у Грибюзера. Оно генериться один раз и лежит в статике...

Во вторых, поисковикам нет необходимости отдавать страницу в полном дизайне и со всеми рюшечками.

В третих, имеет смысл подумать, а нужны ли рюшечки вообще, и если таки нужны, может быть их подгружать черех ajax или еще какую нибудь извращенную вещь (если человек отключил яваскрипт, то значит он спартанец и без списка пользователей обойдется)

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

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

Коммунивер глянул. Извини, но на фоне друпала - очень бледненько. Не говоря уже о базовой функциональности, к друпалу есть несколько тысяч модулей (http://drupal.org/project/Modules), подцеплять которые легко и приятно. А у коммунивера, как я понял, и понятия такого толком нет.
Тот же OpenId, например. Так что, работать может и приятно, но слишком много.

Что в друпале хорошо, можно создавать публикации типа php. Штатными средствами суёшь любой код в любой место. Удобно.

По пунктам.
1. Естественно, генерится при запросе и сохраняется на будущее. Если опять попросят тот же файл и скрипт генерации старше htmlя - отдается старый. Аналогично сделаю с другими форматами.
2.Угу, значит надо их определять как-то. Лень. Но надо. Подумаю.
3.У меня и так рюшечек в разы меньше, чем у остальных библиотек. Боюсь, их только больше станет. А вот ajax - дело хорошее, я к этому двигаюсь (http://lib.rus.ec/list и http://lib.rus.ec/booklib для начала). Поисковикам там ловить нечего. И это тоже плохо.
4. Уж какая есть. Лучше не нашел. Тем более, что список присутствуюших пользователей - а он нужен - меняется постоянно. Да и последние сообщения на форуме... Особо не раскешируешся.
5. Что-то в этом духе есть - http://lib.rus.ec/node/53. Народ ей интенсивно пользуется, но - молча. Там куча неудобностей, но никто ни слова о том, как нужно. Не любят наши люди xml, им wget -m подавай. А ешё лучше - двдишные образы. У меня траффик по http://book.lib.rus.ec в пять раз больше, чем по либрусеку :)

Что касается коммунивера, то:
1. Да, бедненько... Вокруг него нет активного комьюнити...
2. Плагинов там нет. Там есть пакеты. К базвому сайту можно доставить всякие форумы, фотогаллереи. Есть еще чего-то в закрытом коде...
0. Я не уверен, что его достаточно именно вот так просто "глянуть". Много всяких интересных "гитек" явно не описаны нигде...
3. И вообщем на вкус и цвет... Я пхп кушать таки не буду, при практически любом раскладе...


По поводу остального... Там имеет смысл прокомментировать пункт пятый...
Вопервых имеет смысл глянуть вот сюда:
http://www.fictionbook.org/forum/viewtopic.php?t=3297
И возможно сделать так же.
DVD образы, наверное, это хорошая мысль... Если народ их кушает, то имеет смысл делать еже[недельные|дневные|месячные] DVD снапшоты библиотеки... Чтобы народ не парился закачками всего сайта...
Я до сих пор думал, что xml фида будет достаточно, но средний пользователь не осилит с ним что-то внятное сделать, а вот всю библиотеку в виде образа осилит любой средний юзер....

Понимаешь, это буклиб в 23 гига помещается.
А либрусек целиком - под 200. Пока. А со временем доведу до террабайта.
Думаещь, такое тянуть будут?
Мне-то не жалко.

Гм... а может его как-то немого разделить? А то там настолько все в кучу...
На художественное, компьютерное, техническое... Просто разные библиотеки в рамках одного движка...

У справочников по фотошопу и всякой фантастики уж слишком разные целевые аудитории..

Тогда и объем станет значительно меньше...

Не понял, как при разделении объём уменьшится. Скорее, увеличится - у всякого деления найдутся пограничные случаи, которые придётся совать в обе части.
Я, например, читаю и справочники, и фантастику. Не думаю, что я такой уж уникальный.
Да и если делить... Будет вместо одной либы в террабайт три по ~пол. Толку то...

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

Content-Type: text/plain; charset=UTF-8;
Content-Transfer-Encoding: 8bit

Без них письмо показывается неправильно...

Что-то у тебя с почтовым клиентом. У меня всё нормально.
Посмотрю, если найду куда - добавлю.

Это не у меня с почтовым клиентом, это у вас, с соответвием RFC...

Any non-7bit data that is sent without encoding must be properly labelled with a content-transfer-encoding of 8bit or binary, as appropriate.
И
Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of "application/octet-stream" with no parameter sub-arguments. How such data are handled is up to an implementation, but likely options for handling such unrecognized data include offering the user to write it into a file (decoded from its mail transport format) or offering the user to name a program to which the decoded data should be passed as input.

http://tools.ietf.org/html/rfc2049#section-2 (там в самом низу под цифрами 7 и 8)

MIME-Version: 1.0
Туда тоже надо добавить, если уж соответвовать стандарту таки полностью...

Дело вкуса - выбирать программу соответствующую RFC или читающую почту.

Ну... У вас на все найдется внешний виноватый...

У меня не в соотвествии RFC приходят письма из трех мест:
Комментарии из PHPшных форумов
Комментарии из вашей Dupal'овской библиотеки
Комментарии из ЖЖ.

При этом в ЖЖ, я знаю в чем дело, там Mime::Words не умеет уникод... Не успели... А ЖЖсты не заметили...

PHPшные форумы не инкодят 8битные заголовки
Ваша библиотека не отдает заголовки контенттайпе...

Дело всетаки не в почтовике... Как раз наоборот правилньно пользоваться почтовиком в полном соответсвии с RFC дабы дурь каждого была бы видна.

Комментарии из вашей Dupal'овской библиотеки
Комментарии из ЖЖ.

Ну, если так, то я спокоен.
Идеал недостижим, быть на уровне ЖЖ меня устраивает.
Что интересно, с кодировками комментариев из ЖЖ у меня тоже никогда проблем не было.

Вообще, на мой взгляд, все кодировки кроме utf8 не имеют смысла. И, соответственно, права на существование. Надеюсь, они скоро умрут.

А, да.. Еще спам очень часто не соответсвует RFC. Что позволяет тереть письма даже не читая заголовки... Очень удобно.