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

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

А настройки пользователя, обработка кукисов и т.д. Формирование входных данных в виде понятном другим модулям. Ты ж хотел микроядерную архитектуру Значит нужен модуль принимающий запросы и решающий что с ними делать дальше.

Tolka>>Ну и по административным моментам. Начинать мне кажется нужно с чётких задач по пунктам - что должено делать сие ПО. Дать себе труд формализовать это до отмирания всех двойных толкований и недоговорок.
Balancer>Ищутся тактики (по Рейнину), предпочтительно - Доны Кихоты, Максы, Бальзаки и Штирлицы

Я не психолог не по образованию не по увлечениям. Моё предложение чиста пацанская тактика - делать всё какретна за адин раз А значит надо чётко продумать разбивку на модули, жёстко разделить чем они занимаются и самое главное продумать и задокументировать между ними интерфейс, чтобы во время разработки не вносить в него изменеия, которые повлекут за собой переработку сразу нескольких модулей

>>Далее уже прикидывать путь по которому запрос из инета превращается в контент высылаемый пользователю.
Balancer>Это как раз самое простое Сложнее - со всеми проверками и отработками при модификации контента. Ещё сложнее - подать всё в красивом виде. Хороший скин, продуманный интерфейс...[»]

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

Вобщем как я и предполагал чёткого понимания проекта нет. Так что надо делать страничку. И делать всё с самого начала - канкретна чиста

Предлагаю ответить сначала на вопрос:
1. Цель проекта.
Развёрнуто ответить, чтобы вопросов не возникало

Наблюдатель>Tolka, а может просто тему перечитать... на свежую голову? Чиста! Канкретна! Взять и перечитать... Что самое интересное, ты заметишь, что здесь, в этой теме... народ не будет писать конкретику - она для закрытой темы разработчиков. Проект хоть и опенсорсный, но разбрасываться идеями... преждевременно, хотя бы из соображений безопасности. Придёт ушлый дядя и запатентует идеи как свои. Есть и другие резоны ПОКА не светить конкретику на массах...

Чиста перечитал! Канкретна цель проекта до сих пор лишь обозначена намёками Ну хотим движок, ну в общем чтобы круто и удобно и чтобы не платить. Ну лучшебы конечно чтобы расширяемый был, но в общем можно и другие идеи наверно.
А надо чтобы наверно и может быть не было, тогда дело пойдёт быстрее. Потому что если приоритет опен сорс то это опен сорс, а если приоритет быстрота, расширяемость и модульность, то это другое, потому как если проект будет успешно расти то может стать вопрос об оплате костяку разработчиков некоторых денежек, для улучшения и поддержания продукта, так что надо сразу это предусмотреть, в плане организации и учёта вклада, ну и т.д.
А насчёт идей, может я конечно и неправ, но сдаётся мне что всё уже придумано и описано в соответствующей литературе в том числе профессорами и академиками. Остаётся лишь выбрать то что больше всего подходит под наши задачи

Наблюдатель>Взаимодействие между модулями тоже было упомянуто здесь, выше. Я понимаю, что ты хочешь, чтобы ЛИЧНО тебе всё это повторили, но... помилуй! Все сплошь - занятой народ. Так что... "быстро-быстро, сама-сама" (с) Вокзал на двоих

А теперь представь себе середина проекта, на Авиабазе появляется опытный кодер, который смог бы потянуть существенный кусок. И что он должен будет лазить и перечитывать все топики в этом форуме, где 90 процентов воды. Или же просто изучить страничку где коротко ясно и понятно всё описано и есть ссылки на актуальные сейчас форумы.

Наблюдатель>Насчёт Артемия Лебедева... Было очень ценное предложение затачивать движок так, чтобы совместно с ним можно было использовать ЛЮБЫЕ шкурки от ЛЮБЫХ конференций... Модуль конвертации будет не столь велик... Скачал, запустил, конвертнул и... только название движка внизу покажет, что это не Инвижн, не Иконборд и не Юбиби.... Куда здесь Артюшу прикрутить?[»]

К интерфейсу и прикрутим К интерфейсу модуля который формирует все конечные данные для отправки пользователю и передаёт эти данные модулю для формирования конкретной страницы Которую можно заказать и у Лебедева.

Наблюдатель>Здесь нужно остановиться и задуматься - что нам важнее: скорость работы системы модулей или лёгкая расширяемость. Прямые связи всегда быстрее, чем работа через шину (так-ли это?). Уместно-ли здесь аналогия с работой сети (звезда-шина...)? Т.е. нужно учесть и эти тонкости. Целесообразно-ли класть в корень конфиг, где прописаны все установленные модули и их параметры... Новый модуль при инсталляции дописывает себя в конец конфига... Конфиг задаёт поведение взаимодействий модулей. Брррр... системотехники, ау![»]

Через шину плохо. Надо через ядро, потому что технологии меняются, некоторые модули тоже надо будет менять, запаритесь учитывать все модули и перекрёстные ссылки. Надо сделать ядро с жёстким интерфейсом. И к нему цеплять модули по мере надобности. Ядро должно рулить основными функциями - приём от модуля предобработки, запрос в БД или чтение файлов через другие модули и передача на постобработку перед отправкой юзеру. К тому же как поведут себя ловушки (traps) при событийной архитектуре если учесть что ПХП это всё таки довольно далеко от железа, время реакции какое будет, учитывая переключения контекста на загруженных провайдерских веб-серверах.
А по конфигам есть два пути:
1. файл регистра как в винде
2. и директория init.d содержащая конфигурационные файлы, считываемые по порядку при загрузке как в юнихе Можно повесить кнопочку для переконфигурации на "лету" путём повторного прочтения init.d после добавления/удаления очередного конфига.

dreik>как предложение, а как на счёт возможности работы с active directory? [»]

Тогда уж надо ставить вопрос шире. Возможность работать с катологом LDAP. Любым Тем более технология инетовская изначально. Вопрос другой - а надо ли ? Только если создавать сеть распределённых узлов с возможность работы с единой базой сущностей. Но это как говорится вопрос далёкого будущего и относится скорей к модулю аутентификации/авторизации ну и возможно к модулю поиска.

Balancer>Про AD ничего не скажу, а вот LDAP - было бы очень хорошо. Но я с ним совершенно не умею работать
Balancer>Мораль - юзер-интерфейс должен быть отдельным модулем.
Balancer>Что сейчас и есть
Balancer>Простенький интерфейс к БД, обеспечивающий чтение/запись того или иного параметра юзера (в т.ч. совместимый с нынешним iPB), возвращающий идентификатор текущего юзера (по кукам/сессии) и т.п.
Balancer>Про страничку - давайте название придумаем, а там уже и страничку сделаю [»]

Active Directory и есть LDAP-совместимая, объектно-ориентированная, распределённая база данных (каталог), поддерживающая протокол безопасности Kerberos v.5. (так например домен Windows 2000/2003 есть не что иное как сфера керберос). Так что в актив директори можно хранить произвольные объекты со своим уникальным набором атрибутов, можно изменять схему и добалять к уже существующим классам обектов новые атрибуты. Чем собственно говоря активно пользуются такие программы как Exchange и SQL-server например Ну и собстно гибкая система настройки репликации и синхронизации распределённой базы, делегирования полномочий и поиск по всей распределённой базе.

Единственный вопрос о полной совместимости со стандартом LDAP

А по названию надо чтонить исконно-посконное и домотканное Чтобы узнавалось сразу Как например Romych++ B) Или AirForumEngine .
А ещё лучше AirBasic - аналогий очень много
1. AirBasic почти Airbase.
2. Air намекает на воздушность, лёгкость, скорость, на окружающую атмосферу, обстановку, внешний вид (Lingvo 9). Basic означает - составляющий основу, фундаментальный, основной, намекает на простоту его использования, по аналогии с BASIC-ом
3. Ну и вообще - простенько и со вкусом

Наблюдатель>>Здесь нужно остановиться и задуматься - что нам важнее: скорость работы системы модулей или лёгкая расширяемость. Прямые связи всегда быстрее, чем работа через шину (так-ли это?). Уместно-ли здесь аналогия с работой сети (звезда-шина...)? Т.е. нужно учесть и эти тонкости. Целесообразно-ли класть в корень конфиг, где прописаны все установленные модули и их параметры... Новый модуль при инсталляции дописывает себя в конец конфига... Конфиг задаёт поведение взаимодействий модулей. Брррр... системотехники, ау![»]
Tolka>Через шину плохо. Надо через ядро, потому что технологии меняются, некоторые модули тоже надо будет менять, запаритесь учитывать все модули и перекрёстные ссылки. Надо сделать ядро с жёстким интерфейсом. И к нему цеплять модули по мере надобности. Ядро должно рулить основными функциями - приём от модуля предобработки, запрос в БД или чтение файлов через другие модули и передача на постобработку перед отправкой юзеру. К тому же как поведут себя ловушки (traps) при событийной архитектуре если учесть что ПХП это всё таки довольно далеко от железа, время реакции какое будет, учитывая переключения контекста на загруженных провайдерских веб-серверах.

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


Balancer>Мораль - юзер-интерфейс должен быть отдельным модулем.
Какие могут быть сомнения? Я бы сказал не отдельным модем, а отдельными модулями.

Предлагаю следующие имена для проекта:
1. myCMS
2. theCMS
3. openCMS
4. theForum
5. freeCMS
6. CMSnuke
7. magicCMS
8. niagaraCMS
9. tornadoCMS
10. boraCMS
11. samumCMS
12. novicCMS, novikCMS, novikForum
13. migCMS, suCMS
14. spiderCMS
15. tarakanCMS
16. spaceCMS, spaceForum
17. rocketCMS, rocketForum
18. supersonicCMS :ph34r:

Tolka>если учесть что ПХП это всё таки довольно далеко от железа, время реакции какое будет, учитывая переключения контекста на загруженных провайдерских веб-серверах.

Время обработки PHP кода на форумах составляет обычно считанные проценты загрузки. Основне время - MySQL-запросы.

S.P.>1. myCMS

Намёк на MySQL - не годится, т.к. он у нас будет не обязательным

S.P.>2. theCMS

Хорошо... Нравится

S.P.>3. openCMS
S.P.>5. freeCMS

Тоже нормально, но очень уж их много, этих openXXX и freeXXX

S.P.>4. theForum

У нас же не только форум. CMS = Форум + Wiki + ...

S.P.>6. CMSnuke

Обычно *nuke - это наследники phpNuke

Наблюдатель>...есть только миг, между прошлым и будущим...
Наблюдатель>чем не слоган для migCMS? Т.е. "mig" - есть карашо! Остальное... CMS? не знаю... Это всё равно, что писать LinuxOS. Зачем в названии указывать класс системы?

Чтобы было понятно, что это такое BeOS, OS/2 ...

>Наблюдатель>Mig (copyleft) 2004 CMS

MiG, таки, думаю давно (tm), (R) и т.п.

Наблюдатель>Миг - это понятно каждому во всём мире - это НАШЕ...

Это - да

Tolka>Альтернатива изначально хорошо продуманному и жёстко прописанному интерфесу с ядром есть плохо продуманный интерфейс, меняющийся во время разработки. Теперь представьте что вы пишите модуль и тут вдруг понимаете что не продумали функционал и вам нужны ещё 2 дополнительные глобальные переменные

Глобальные переменные - зло!
В текущей версии обычны только глобальные константы

Tolka>Тем более этож интерфейс только с ядром - его функции в хорошо продуманной системе неизменны в течении долгих лет, и при хорошо продуманном жёстком интерфейсе это наоборот делает систему гибче и масштабируемей [»]

Вот потому я и не спешу. Ужасно не люблю менять интерфейсы даже в собственных проектах