Comments 21
Вырисовывается новый уровень абстракции... =)
В принципе, в той или иной мере многие уже реализовывали для своих проектов взаимодействие гетерогенных систем. В качестве протокола обмена управляющими командами и информацией обычно используют SOAP.
Всё же это достаточно редкая задача, нужно сказать. Может понадобиться для нескольких проектов, но широкой аудитории эта вещь не нужна, мне кажется.
Я бы посмотрел на реализацию...
В принципе, в той или иной мере многие уже реализовывали для своих проектов взаимодействие гетерогенных систем. В качестве протокола обмена управляющими командами и информацией обычно используют SOAP.
Всё же это достаточно редкая задача, нужно сказать. Может понадобиться для нескольких проектов, но широкой аудитории эта вещь не нужна, мне кажется.
Я бы посмотрел на реализацию...
пока что все на уровне идеи, одному человеку такой проект поднять не под силу, поэтому вынес на обсуждение
Слишком много хаоса в объединяемых компонентах. Мне кажется, что даже если и получится склеить все в кучу, то после этого код придется замораживать. Потому что после пары апдейтов любого из компонентов все с очень высокой долей вероятности поползет вкривь и вкось.
центральный элемент призван упорядочить хаос, по крайней мере в сфере юзер-даты. т.е. разные системы инфу дают по разному, UMS предоставляет её разным системам в соответствии с их требованиями, но внутри себя хранит информацию упорядоченно...
а апдейтить надо только один модуль для UMS для каждой системы - это уже как мне кажется вопросы разработчиков систем и расширений/модулей...
а апдейтить надо только один модуль для UMS для каждой системы - это уже как мне кажется вопросы разработчиков систем и расширений/модулей...
Почему же не под силу? Я не вижу что-то особенно сложное в реализации этой идеи. Народ нужен разве что на тест. =)
Как я себе вижу решение:
- определяемся с целями проекта (зайдёт ли это дальше единого входа);
- пишем абстрактный класс для манипулирования CMS (на этом моменте и закладываем работу с модулями):
- пишем модули для работы с распространёнными CMS.
Теперь вопрос: что можно ещё кроме единого входа реализовать?
И другой вопрос: а чем любая платформа вроде SharePoint не подходит для разворачивания блогов, сайтов и прочих структурных единиц в рамках одной фермы серверов? Или принципиально объединять именно разные CMS?
Как я себе вижу решение:
- определяемся с целями проекта (зайдёт ли это дальше единого входа);
- пишем абстрактный класс для манипулирования CMS (на этом моменте и закладываем работу с модулями):
- пишем модули для работы с распространёнными CMS.
Теперь вопрос: что можно ещё кроме единого входа реализовать?
И другой вопрос: а чем любая платформа вроде SharePoint не подходит для разворачивания блогов, сайтов и прочих структурных единиц в рамках одной фермы серверов? Или принципиально объединять именно разные CMS?
"- определяемся с целями проекта (зайдёт ли это дальше единого входа)" - скорее да...
"что можно ещё кроме единого входа реализовать?" - единый выход :)))) если серьезно - управление юзер-датой, бан, разбан, расширенный профиль, последние посты, комменты пользователя и т.д.
"Или принципиально объединять именно разные CMS?" - именно в этом суть идеи. ведь даже при объединении двух систем есть проблемы...
"что можно ещё кроме единого входа реализовать?" - единый выход :)))) если серьезно - управление юзер-датой, бан, разбан, расширенный профиль, последние посты, комменты пользователя и т.д.
"Или принципиально объединять именно разные CMS?" - именно в этом суть идеи. ведь даже при объединении двух систем есть проблемы...
"Почему же не под силу? Я не вижу что-то особенно сложное в реализации этой идеи." - для стабильной совместимости, нужны разработчики знающие эти системы и имеющие опыт разработки в совмещаемых системах...
=) Насколько я понимаю, работа будет всё равно вестись на уровне доступа к базе данных. Считаю, что это самый "тру" способ, ибо связывать API разных CMS уж точно геморрой. А в связывании CMS на уровне базы данных ничего сложного нет, весь вопрос именно в модулях-драйверах, да в уровне архитектуры и реализации баз данных.
>Я не вижу что-то особенно сложное в реализации этой идеи.
Попробуйте ;)
Попробуйте ;)
CMS2 )))
UFO just landed and posted this here
Мидделвар это: а не UMS
Кстати для Джумлы есть много интеграций:
1. джумла - медиа-вики;
2. джумла - доку-вики;
3. джумла - форум SMF;
4. джумла - форум PHPBB;
5. джумла - форум VB;
6. джумла - форум IPB;
7. джумла - форум PanBB;
4. джумла - WP...
Идея UMS довольно-таки интересная, но думаю не совсем реализуема с учетом всех обновлений всех систем
1. джумла - медиа-вики;
2. джумла - доку-вики;
3. джумла - форум SMF;
4. джумла - форум PHPBB;
5. джумла - форум VB;
6. джумла - форум IPB;
7. джумла - форум PanBB;
4. джумла - WP...
Идея UMS довольно-таки интересная, но думаю не совсем реализуема с учетом всех обновлений всех систем
для джумлы вот вы навскиду привели 8 модулей интеграции. когда можно было бы написать один для UMS.
точно так же, для smf - для которого тоже куча модулей интеграции - можно было бы написвать один модуль для "ядра" - UMS.
и так далее...
точно так же, для smf - для которого тоже куча модулей интеграции - можно было бы написвать один модуль для "ядра" - UMS.
и так далее...
Да, но как это все реализовать с учётом апдэйтов?
А то на выходи может получится совершенно новая система :)
А то на выходи может получится совершенно новая система :)
ну вот же я вроде написал...
могу даже добавить, что если позиционировать UMS как ядро, можно прийти к CMS2.0, состоящей из ядра (ums), модуля форума (phpbb, vanilla), модуля wiki и т.п.
могу даже добавить, что если позиционировать UMS как ядро, можно прийти к CMS2.0, состоящей из ядра (ums), модуля форума (phpbb, vanilla), модуля wiki и т.п.
Невозможно! Эта вещь будет тяжела до невозможности -одни запросы к базе... нагрузят сервер дай боже как...
Sign up to leave a comment.
Идея для проекта — UMS.