Узкие места и проблемы, требующие решения в новой версии

[Борис Бердичевский]

Вот это интересно (по ссылке от rxu), над этим следует крепко подумать (мне).

MODS
We need to figure out what kinds of modifications, plugins, addons or extensions we'll have and settle on names for these as early as possible. So that it's clear what's meant in discussions. We also need to come up with a good set of basic feature additions & modifications that we can implement to see whether the architecture can really deal with the modifications/plugins/addons/... as well as we anticipated.

Первая идея, которая приходит в голову, -- модульность на странице показа Конференции, Топика, Темы. Чтобы был довольно простой способ "вписать" в показ Модуль кнопок, Модуль сообщения (поста), Модуль подписи, Модуль юзера, Модуль смайликов, Модуль ответа и т.д.
Такая структуризация позволит несложным способом вводить измененные в плагинах/модах/аддонах элементы показа. И соответственно php-модули для обработки/формирования этих элементов показа.

[SvS]

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

Кстати - да! Даже для небольших форумов хостинг надо очень и очень тщательно выбирать. Это еще одно направление - оптимизация.

[Mr. Anderson]

Это еще одно направление - оптимизация.

Нельзя получить все и сразу, и при этом нифига "не заплатив" ресурсами.
Люди, будьте же реалистами...

[SvS]

Mr. Anderson
Опять же приведу пример Drupal - там уже есть это "всё и сразу" и без такой дорогой оплаты ресурсами.
Вам ли не знать об этом

[Mr. Anderson]

SvS
В друпале все из сразу? Из коробки - нет. Да и его непрожорливость - не более, чем миф. Ровно такой же, как миф о прожорливости тройки.

[Rayden]

Первая идея, которая приходит в голову, -- модульность на странице показа Конференции, Топика, Темы. Чтобы был довольно простой способ "вписать" в показ Модуль кнопок, Модуль сообщения (поста), Модуль подписи, Модуль юзера, Модуль смайликов, Модуль ответа и т.д.
Такая структуризация позволит несложным способом вводить измененные в плагинах/модах/аддонах элементы показа. И соответственно php-модули для обработки/формирования этих элементов показа.

Это даст дикую дополнительную нагрузку на сервер, плюс сильно ограничит возможности этих модулей.

[Борис Бердичевский]

Даже если модули будут входить в единый HTML? Возрастёт нагрузка?
Я же не написАл, что это должны быть фреймы, -- это должны быть куски HTML.

[Rayden]

Ты вообще понимаешь, какую херню несешь?

Вот примитивный мод - вывести на индексе внизу список именинников в ближайшую неделю. Мод 'Upcoming Birthday list'
Что он делает: из index.php вызывается functions_upcbirthdays.php
Там идет запрос к базе и отбор нужных именинников.
Формирование массива для передачи в шаблон.
Далее в шаблоне index_body.html выделяется специальное место, куда впечатывается список именинников.

Ты запросы к базе на хтмл будешь делать? Интересно посмотреть.

[rxu]

Rayden
Скорее всего, имеются ввиду заранее размеченные области - блоки, в которые моды/плагины могут выводить результаты своей работы. На Друпале примерно так.

[Rayden]

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

[Борис Бердичевский]

Я имел в виду структуризацию всего этого и разработку неких правил для включения нового модуля показа или модификации существующего.
Да, обращение к БД будет из <что-то>.php, да, будут выделяться массивы по определённым правилам. А на ограничение области показа -- никакого влияния. Тот, кто будет модифицировать, будет отвечать за компоновку страницы.
Речь -- только о правилах добавления и модификации модулей, чтобы делать безболезненные переходы к новым версиям, объединяемые с модами.
Ещё -- почему сейчас идут довольно сложные объединения модов -- это из-за недостаточного выделения базовой функциональности в процедуры-чёрные ящики. Слишком часто для разработки мода приходится спускаться на самый нижний уровень кода, задевать что-то базисное. И в конечном итоге очередная версия с базисными правками сводит правки мода на нет. Точнее, проще сдублировать правки мода на "чистом" обновлённом коде.

[SvS]

В друпале все из сразу? Из коробки - нет. Да и его непрожорливость - не более, чем миф. Ровно такой же, как миф о прожорливости тройки.

Я вам могу легко доказать, что друпал с десятком доп. модулей (не считая десятка из "коробки"), обеспечивающих нужный функционал, жрёт ресурсов втрое меньше, чем абсолютно голый phpbb 3.0.6 на одном и том же сайте, с 20-30 посетителями в сутки. Просто не хочется выкладывать эту инфу - очень много там "затушёвывать" надо. После сноса форума с сайта "варнинги" (превышение нагрузки на проц более 10%) вместо 20-30 в сутки стали ровно ноль, а среднестатическая нагрузка на проц упала в 4 раза.
Поставить и настроить этот десяток модулей в друпале - 2-3 часа, а сколько времени надо потратить на десяток модов?
Вот сколько думаю - так и не могу понять: за счёт чего phpbb3 так ресурсоёмок и так сложен в модификации по сравнению с популярными CMS, одной из которых он по сути сам и является. Заметил, что phpbb (тем более - версий 3) очень редко используют на "серьёзных" ресурсах - не поэтому ли?

[Rayden]

SvS
угу, Друпал у тебя в основном читает из базы, а форум активно в нее пишет, что на порядки накладнее.

[Mr. Anderson]

Я вам могу легко доказать

Просто не хочется выкладывать эту инфу

QED.

После сноса форума с сайта "варнинги" (превышение нагрузки на проц более 10%) вместо 20-30 в сутки стали ровно ноль, а среднестатическая нагрузка на проц упала в 4 раза.

О чем это должно говорить?

Поставить и настроить этот десяток модулей в друпале - 2-3 часа, а сколько времени надо потратить на десяток модов?

Иногда - не более 2 минут. Иногда - не более 2 часов.

Вот сколько думаю - так и не могу понять: за счёт чего phpbb3 так ресурсоёмок

Вот сколько думаю так и не могу понять - почему юзеры верят в мифы, большую часть из которых они сами и рождают.
Для тех, кто в танке - подобные утверждения нужно подтверждать хотя бы "голыми цифрами" а вы, учитывая вашу неспособность даже адекватно выразить абстрактную базисную мысль, врядли можете сие сделать. Ничего личного, просто надоело читать сказки.

Заметил, что phpbb (тем более - версий 3) очень редко используют на "серьёзных" ресурсах - не поэтому ли?

А что такое серьезные ресурсы?
И если на "серьезных" ресурсах не используется продукт Н, то это... показатель чего?

[SvS]

Друпал у тебя в основном читает из базы, а форум активно в нее пишет, что на порядки накладнее

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

Иногда - не более 2 минут. Иногда - не более 2 часов.

Это на десяток модов с настройкой? ;) Ню-ню, как говорится...

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

Потому что у них есть глаза!

подобные утверждения нужно подтверждать хотя бы "голыми цифрами"

А это - не цифры?

После сноса форума с сайта "варнинги" (превышение нагрузки на проц более 10%) вместо 20-30 в сутки стали ровно ноль, а среднестатическая нагрузка на проц упала в 4 раза.

А что такое серьезные ресурсы?

В моём понимании и в данном контексте это, например, форумы техподдержки крупных компаний, где огромная посещаемость и спецы-оптимизаторы, выбирающие софт для сайта вовсе не "от балды" и не по юзерскому принципу "где лучше саппорт" (т.к не нуждаются в нём) и где цена скрипта не определяет.
http://forum.dlink.ru/, http://forum.asus.ru/ и другие до сих пор почему-то не сконвертировали форумы в phpbb3. Не уж-то не умеют или денег на фрилансеров жмутся? Или лохи-админы? :lol: