Итак, о проекте нового движка форума

В свете перехода форума Invision на платную основу, возникла давно назревшая идея писать свой форум или примыкать к какому-то имеющемуся проекту с целью его развития. Однако, ни одного открытого проекта, удовлетворяющего моим требованиям на сегодня я не знаю. Если есть что-то подобное - ткните пальцем

Пока же - общие мысли.

Основныим идеями моего движка будут:

• GPL-лицензия
• Базирование на готовых GPL-решениях, типа Smarty (шаблоны, скины) и ADODB (доступ к разным БД)
• Расширяемость "без хаков" - т.е. возможность расширения модами и хаками средствами движка
• На этой основе, например, сменные модули тех же скинов, способные использовать скины чужих форматов и т.п.
• Ориентация на большие БД (сотни тысяч и миллионы записей)
• Интерфейс для интеграции с различными объектно-ориентированными CMS
• Отдельные опциональные Wiki-элементы (сохранение версий при редактировании постингов, боле гибкая разметка и т.п.)

По технической части

• Языком программирования предполагается PHP, хотя этот выбор ещё остаётся под вопросом.
• БД будет отвязана от форума минимум одним промежуточным интерфейсом, так что сам форум останется БД-независисмым. Предполагается сменный драйвер, позволяющий работать через другие решения, например, через тот же ADODB. Или даже через plain/text-файлы (для тех, кому не требуется большой форум и не возможности ставить БД)
• Для шаблонов будет использоваться Smarty.
• Скины можно будет конвертировать из имеющихся коллекций iPB, phpBB и т.п. Хотя при этом острее встанет вопрос реализации дополнительных функций. Эта тема требует особенной проработки.
• Языком разметки будет мой BB-ориентированный LCML, используемый сейчас на сайте.

При отсутствии поддержки ожидаемый срок доведения до нынешней функциональности форума - год или полтора. До выведения на современый к тому времени и совершенно конкурентноспособный уровень - два .. два с половиной года.

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

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

Ладно, пока хватит

Так, продолжу мысли.

• Естественно, форумы должны быть произвольной вложенности
• Нужно рассмотреть вопрос скорости обработки простых объединёных запросов по нескольким таблицам против одного по таблице совмещённой. Это могло бы позволить реализовать объектную модель сообщений и форумов на манер задействованной сейчас на сайте.

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

Ребята! Зайдите ко мне хоть на Арбуз, хоть на СтопХак (см. мою подпись) - гляньте объяву. Разместите у себя аналогичные объявления... У вас же есть свои ресурсы... Втихушку, междусобойчиком ничего не получится...

Может смогу быть в чем то полезным.

Вдруг пригожусь? На счет программирования - это вряд ли, окромя фортрана (90, 95) больше мало чего знаю, но там тестирование, оформление, и др. ... с точки зрения пользователя.
(Может, по ходу дела, и научусь чему-нибудь )

Balancer:

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

 

В общем явно напрашивается система a'la Forth.

A+B+C+D вещи несовместимые

 

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

По моему, ты, Рома, собирался сделать новую игру типа космическая стратегия. Забыл?

>B. Языком программирования предполагается PHP, хотя этот выбор ещё остаётся под вопросом.

Ненавижу PHP. Уж лучше Це тогда!

А народ от дела ушел в обсуждение =( причем совершенно не того что нужно.

Balancer>Только и делу это, в общем-то, пока не мешает.
обсуждение хорошо когда есть что обсуждать, а из пустого в порожнее переливать - разговоров много толку 0.
Balancer>Другое дело, что у меня совершенно нет опыта работы в команде, так что не знаю, чем делиться (из мыслей и наработок) в первую очередь. По старой привычке пока всё в одиночку думаю
найти бы тогда PM'а, такие знают что делать и чем делиться =) Ну а для начала надо определить хотя бы цели и задачи. Потому как задача - написать форум не хуже нынешнего, она ни о чем не говорит.

Ок, тогда потихоньку начну задавть вопросы...

Balancer>*По технической части*
Balancer>* Языком программирования предполагается PHP, хотя этот выбор ещё остаётся под вопросом.

в общем то исходя из Smarty и ADODB, получается что только PHP, потому как эти вещи PHP ориентированы =) Ну да не суть, ядро и функционал может быть на PHP, а допустим рутинные вещи вроде перевода старых топиков в статичный арихив можно и на Perl сделать.

Balancer>* БД будет отвязана от форума минимум одним промежуточным интерфейсом, так что сам форум останется БД-независисмым. Предполагается сменный драйвер, позволяющий работать через другие решения, например, через тот же ADODB. Или даже через plain/text-файлы (для тех, кому не требуется большой форум и не возможности ставить БД)

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

Balancer>* Для шаблонов будет использоваться Smarty.

и

Balancer>* Скины можно будет конвертировать из имеющихся коллекций iPB, phpBB и т.п. Хотя при этом острее встанет вопрос реализации дополнительных функций. Эта тема требует особенной проработки.

phpBB скины достаточно близки по идеологии к шаблонам Smarty, чего не скажешь о IPB. Стоит ли вообще заниматься этой проблемой, ведь можно убить кучу времени и при том не получить универсального конвертера.

Далее одной из задач которая ставится - скорость работы. Smarty и ADODB функциональны, но и в то же время снижают скорость работы. Более того наврятли будут использоваться более 50% возможностей того же Smarty... ADODB универсальная обертка для работы с различными БД серверами, это хорошо с одной стороны свобода выбора, но с другой стороны пользователь будет использовать в конечном итоге определенный сервер и лишний функционал по поддержкуе скажем Oracle или PostgreSQL ему уже не нужен будет.

Остальные наработки читаю, из них вывод сделал, что будет использован ООП подход при разработке, очевидно, что что то очень близкое к MVC модели. Потому очень интересно как система будет опознавать какие ей модули нужны, или она вообще будет подключать все имеющиеся модули сразу. Что понимается под ядром системы и какие функции оно должно реализовать.

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

За сим все, сумбурненько так получилось...

Vanish>Ок, тогда потихоньку начну задавть вопросы...

Поехали

Vanish>в общем то исходя из Smarty и ADODB, получается что только PHP, потому как эти вещи PHP ориентированы =)

Да у меня это как бы подразумевается. Особенно - учитывая нынешнюю распространённость языка Просто, на всякий случай этот вопрос открытым оставляю

>а допустим рутинные вещи вроде перевода старых топиков в статичный арихив можно и на Perl сделать.

В этом смысле Perl ничуть не лучше PHP Так что - без особой разницы.

Vanish>Не очень ясно про промежуточный интерфейс. Если я правильно понимаю будет попытка создания универсального интерфейса позволяющего работать с различными решениями вроде ADODB. Имеет ли это смысл?

Функциональности ADODB очевидно мало Во-первых, это уже явная заточка под SQL, что не обязательно для малых и мредних систем (моя система благополучно жила на плоских файлах года два, если не три ), во-вторых, там недостаёт функциональности. Так что вылезают следующие уровни:

• Уровень абстракции БД (без привязки к SQL!) - либо полностью автономный (как сейчас), либо надстройка над тем же ADODB, чтобы одним драйвером обеспечить, скажем, совместимость сразу с рядом SQL-систем
• Уровень работы с объектами, надстройка над ДБ-драйвером. Лучше не совмещать с ним, т.к. позволит вынести много общего кода, упростив написание драйверов под иные форматы хранения данных.
• Собственно, уровень приложения, когда скрипт системы обращается к БД, извлекает что надо и т.п.

Ну, от балды, простейший реальный пример:

1. <?
2. $page = 'http://airbase.ru/hangar/';
3. $hts = new DataBaseHTS();
4. $title = $hts->get_data($page, 'title');
5. ?>

Класс DataBaseHTS при создании, если нужно, создаст экземпляр класса доступа к БД, если уже таковой есть - возьмёт ссылку на него из глобального кэша.

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

Вообще, высокий уровень абстракции делает программирование системы очень простым и компактным, а за счёт возможности потратить свои временные ресурсы на оптимизацию алгоритмов - ещё и быстрым. Скажем, весь код вывода страниц сайта у меня укладывается в 158 строк (работа со Smarty).

Vanish>phpBB скины достаточно близки по идеологии к шаблонам Smarty, чего не скажешь о IPB. Стоит ли вообще заниматься этой проблемой, ведь можно убить кучу времени и при том не получить универсального конвертера.

ИМХО, стоит. В случае успеха выигрышь будет колоссальным. Сотни скинов от основных фаворитов. От лаконичных phpBB до наворочанных iPB.

В случае iPB, конечно, придётся повозится, но оно того стоит.

Vanish>Далее одной из задач которая ставится - скорость работы. Smarty и ADODB функциональны, но и в то же время снижают скорость работы. Более того наврятли будут использоваться более 50% возможностей того же Smarty...

Ну, у меня пока Smarty только ускоряет работу и мою и скриптов Во-первых, у него очень хорошая система кеширования, которая легко управляется моим движком, во-вторых, он очень экономит время разработки. Я не на 50%, я, дай Бог, на 20% использую этот движок. Но я на нём сэкономил, м.б. месяц времени разработки и имею очень хорошую производительность

>ADODB универсальная обертка для работы с различными БД серверами, это хорошо с одной стороны свобода выбора, но с другой стороны пользователь будет использовать в конечном итоге определенный сервер и лишний функционал по поддержкуе скажем Oracle или PostgreSQL ему уже не нужен будет.

Вот про ADODB ничего не скажу, сам его прямо не использовал, только в сторонних продуктах.

Но всё ещё проще. Драйвер БД будет отдельным и изначально ориентированным на MySQL (хотя бы потому, что ADODB сейчас не совместим с MySQL 4.1.x, который я использую ), но его, после переноса в него части кода из объектного драйвера, будет легко переписать под любую систему. Как нативную БД, так и универсальный лейер. В любом случае непосредственно сейчас я этим заниматься не буду Нам бы запустить функционал форума на MySQL

Vanish>Остальные наработки читаю, из них вывод сделал, что будет использован ООП подход при разработке, очевидно, что что то очень близкое к MVC модели.

Не слышал про MVC, или слышал, но не ассоциирую название

>Потому очень интересно как система будет опознавать какие ей модули нужны, или она вообще будет подключать все имеющиеся модули сразу.

Сейчас система подключаемых модулей реализована в компиляторе языка разметки. Там все модули подключаются разом. Пре- и постобработка просто обрабатывают текст. Функции обработки тэгов компилируются, и вызываются парсером по мере надобности (т.е. обработка тэгов, которые не встречаются в тексте не происходит)

Что приходит в голову по дальнейшей декомпозиции:

• Вынос в модули функций создания страниц (т.е. тот же нынешний Smarty-модуль)
• Разделение нынешнего объектного модуля на три части (считывание данных, запись данных и обработка данных) и вынос их в отдельные модули. Это позволит легко и прозрачно переключаться от одного метода хранения данных к другому.

>Что понимается под ядром системы и какие функции оно должно реализовать.

Связка всех модулей

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

Ещё поройся в топике Что есть работающего в данный момент

Я тебе еще года 2 назад говорил о самодельном форуме. Все течет, все меняется.

Не против принять участие.
С чего начинать. Дизайна еще нет? B)

Дизайна ещё нет

Ну с него и нужно начать.
Требования ты сформулировал глобально. Давай уточнять. Глобальные изменения в GUI, с точтки зрения юзера, будут?

Будет ли проект рассчитываться на плоское отбражение или нет? Дело в том, что с точки зрения юзверя нормальный иерархический форум, типа ВИФ'ов удобнее плоского. Можно следить за логикой. В iPB есть подобный режим, но неуверен, что им кто-либо пользуется, т.к. он не умолчальный. И, конечно с ВИФ'овскими по удобству не сравним.