расширение ejabberd модулями для пользовательской схемы mysql?

Вместо ejabberd.sql я использую пользовательский Схема MySQL (из-за устаревших причин).

Я буду выполнять некоторые операции с БД для определенных действий, таких как Ping, Pong, доставка сообщений, чтение сообщений и, что наиболее важно, получение / настройка списка реестров и объявление о присутствии (все это по моей собственной схеме).

Однако кажется, что ejabberd везде использует ejabberd.sql, и его исходный код в значительной степени зависит от него. Возиться с исходным кодом — последнее, что я стал бы делать, поскольку я не знаю о его зависимостях.

Возможные идеи:

Скажем, если я расширим ejabberd, написав свои собственные модули, то какая польза от mod_roster_odbc? Я просто не хочу терять все функциональные возможности ejabberd, но у меня нет другого выбора, кроме как использовать здесь пользовательскую схему.

OR

Нужно ли мне модифицировать каждый запрос в odbc_queries и ejabberd_odbc. Если есть некий централизованный модуль, который позволит мне модифицировать запросы, отражая их везде, не нарушая гармонии ejabberd, было бы здорово .

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


person HIRA THAKUR    schedule 17.11.2014    source источник
comment
Вы, вероятно, должны получить награду - я не думаю, что ситуация или решение полностью соответствуют сценарию, который вы изначально предполагали.   -  person zxq9    schedule 21.11.2014
comment
Я не думаю, что мы сможем отменить награду. Не стесняйтесь редактировать вопрос, если вы считаете, что это может иметь какое-то значение.   -  person HIRA THAKUR    schedule 21.11.2014
comment
@zxq9 zxq9: я работаю над возможностями, давайте посмотрим. Я постараюсь не беспокоить ejabberd, если это возможно. Спасибо   -  person HIRA THAKUR    schedule 21.11.2014


Ответы (1)


EDIT Изменение этого ответа после получения дополнительной информации о ситуации с ОП.

Вариант использования, который вы имеете в виду, требует четкого разделения ваших основных бизнес-данных и службы чата. Чат следует рассматривать как внешний сервис, а не как неотъемлемую часть всей системы (даже если это «основной» сервис с точки зрения пользователя, чат никогда не должен быть жестко встроен, скажем, в управление учетными записями).

Используйте существующую инфраструктуру в качестве места, где происходит аутентификация, и независимо настройте чат с помощью ejabberd и настройте его для выполнения внешних аутентификационных вызовов к вашему основному сервису.

Если вам требуется сохранение или включение ваших устаревших данных чата, вы можете импортировать их в схему ejabberd (не очень удобно) или оставить устаревшую систему чата в «режиме только для чтения» и заставить все новые чаты проходить через ejabberd (лучше, особенно если вы потратите время на то, чтобы сделать интерфейс удобным для пользователей). Если вам нужны устаревшие данные для аналитических целей, вы должны экспортировать их в схему аналитики и извлечь (пакетно, неуклюже) или отразить (вживую, намного лучше) данные ejabberd в ту же схему для анализа.

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

person zxq9    schedule 21.11.2014