用自定义mysql架构的模块扩展ejabberd?

时间:2014-11-17 12:00:40

标签: erlang xmpp ejabberd otp

而不是ejabberd.sql,我正在使用自定义MySQL架构(由于遗留原因)。

我将对某些活动进行一些数据库操作,如Ping,Pong,Msg deliverd,Msg read以及最重要的是获取/设置名单列表并宣布存在(所有这些都在我自己的架构上)。

然而,ejabberd似乎始终使用ejabberd.sql,它的源代码几乎都依赖于它。由于我不知道它的依赖性,所以我会做最后一件事。

可能的想法:

让我们说如果我通过编写自己的模块来扩展ejabberd,那么mod_roster_odbc会有什么用处?我只是不想放弃ejabberd的所有功能,但我没有其他选择,只能在这里使用自定义模式。

OR

我是否需要修改 odbc_queries和ejabberd_odbc 中的每个查询。如果有一个集中模块可以让我修改查询,在不影响ejabberd的和谐的情况下反映它,它会很棒的。

总而言之,我希望避免处理依赖关系并尽可能以最聪明的方式完成我的工作。但我对最佳方法可能是什么感到非常模糊?

1 个答案:

答案 0 :(得分:1)

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

您想到的用例需要在核心业务数据和聊天服务之间进行强有力的分离。聊天必须被视为一种外部服务,而不是整个系统不可或缺的东西(即使从用户的角度来看,它是一种核心"服务,聊天也不应该硬连接到帐户管理中) )。

将现有基础架构用作进行身份验证的位置,并使用ejabberd独立设置聊天,并将其配置为对核心服务进行外部身份验证调用。

如果您需要持久性或包含旧聊天数据,可以将其导入ejabberd架构(不太好),或将旧聊天系统保留在"只读模式"并让所有新的聊天通过ejabberd(更好,特别是如果你花时间使界面与用户无缝)。如果您需要遗留数据用于分析目的,那么您应该将其导出到分析模式并提取(批处理,笨拙)或反映(实时,更好)ejabberd数据到同一模式进行分析。

无论你做什么,都不会给核心系统带来聊天任务负担,并且不会给聊天系统带来分析责任。如果您的系统非常大或具有显着的稳健性要求(并且您的预算适合),这些应该是非常独立的,甚至可以在不同的硬件上运行。