扩展ejabberd与自定义mysql模式的模块？ [英] extending ejabberd with modules for custom mysql schema?

问题描述

而不是 ejabberd.sql ，我是使用自定义的MySQL模式（由于遗留的原因）。

我将在某些活动上进行一些数据库操作，如Ping，Pong，Msg deliveryd，Msg阅读，最重要的是获取/设置名单列表并宣布存在（所有这些都在我自己的架构上）。

然而，ejabberd似乎全部使用ejabberd.sql，其源代码很漂亮很依赖于它。与源代码匹配是我不知道它的依赖关系的最后一件事。

可能的想法：

如果我通过编写自己的模块来扩展ejabberd，那么mod_roster_odbc将会使用什么？我根本不想放弃ejabberd的功能，但我没有别的选择，比在这里使用自定义模式。

或

我需要修改每一个qu在 odbc_queries和ejabberd_odbc 中，如果有一个集中的模块可以允许我修改查询，反映它在任何地方，而不打扰ejabberd的和谐，这将是巨大的。

总而言之，我想避免解决依赖关系，并以最聪明的方式完成我的工作。但是对于最好的方法可能是很模糊的。

解决方案

编辑在了解OP的情况后，更改此答案。

您所考虑的用例要求您的核心业务数据和聊天服务之间的分离。聊天必须被视为外部服务，而不是整个系统的一部分（即使从用户角度来看是一种核心服务），聊天也不应该被硬连接到帐户管理中。 >

使用现有的基础设施作为认证发生的地方，并使用ejabberd独立设置聊天，并配置它以对您的核心服务进行外部认证呼叫。

如果您需要持久化或包含旧版聊天数据，您可以将其导入到ejabberd模式（不太好），或将旧聊天系统保留在只读模式中，并使所有新的聊天通过ejabberd（更好的，特别是如果你花时间使界面无缝的用户）。如果您需要遗留数据进行分析，那么您应将其导出到分析模式，并提取（批量，笨拙）或将ejabberd数据反映（实时，更好地）到同一模式进行分析。

无论你做什么，都不要为核心系统负责聊天工作，不要为分析工作负担。如果您的系统非常大或具有强大的鲁棒性要求（而且您的预算适合），这些应该是强大的独立性，即使运行在不同的硬件上。

Instead of ejabberd.sql,I am using a custom MySQL schema(because of legacy reasons).

I will be doing some DB operations on certain activities like Ping,Pong,Msg deliverd,Msg read and most importantly getting/setting roster list and announcing presence(all of these on my own schema).

However,ejabberd seems to use ejabberd.sql all throughout and its source code is pretty much dependent on it.Fiddling with the source code is the last thing I would do since I am not aware of its dependencies.

Possible ideas :

Lets say if I extend ejabberd by writing my own modules,then what use will mod_roster_odbc be?I simply dont want to loose on all functionality of ejabberd but I have no other option than using custom schema here.

OR

Do I need to modify each and every query in odbc_queries and ejabberd_odbc.If there is a certain centralized module which can allow me to modify queries,reflecting it everywhere without disturbing the harmony of ejabberd,it would be great.

All in all,I want to avoid tackling dependencies and getting my work done in smartest way possible.But I am pretty vague about what the best approach might be?

解决方案

EDIT Changing this answer after learning more about the OP's situation.

The use-case you have in mind calls for strong separation between your core business data and the chat service. Chat must be thought of as an external service, not something integral to the overall system (even if it is a "core" service from a user perspective, chat should never be hard-wired into, say, account management).

Use the existing infrastructure as a place where authentication takes place, and set chat up using ejabberd independently and configure it to make external authentication calls to your core service.

If you require persistence or inclusion of your legacy chat data, you can import it to the ejabberd schema (not so great), or leave the legacy chat system in "read only mode" and make all new chat go through ejabberd (better, especially if you take the time to make the interface seamless to users). If you need the legacy data for analytical purposes, then you should export it to an analytics schema and extract (batched, clumsy) or reflect (live, much better) the ejabberd data to the same schema for analysis.

Whatever you do, don't burden the core system with chat duties, and don't burden the chat system with analytical duties. These are things that should be strongly independent, even running on different hardware if your system is either very large or has significant robustness requirements (and your budget fits).

这篇关于扩展ejabberd与自定义mysql模式的模块？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！