GSOC 2016

54 views
Skip to first unread message

sahilsha...@gmail.com

unread,
Mar 8, 2016, 9:22:37 AM3/8/16
to BEAM Community
Hello everyone out there. My name is Sahil Sharma. At present I'm in 3rd year and pursuing B.Tech. from National Institute of Technology, Hamirpur , India. I'd like to contribute to Beam community  and interested in implementation of XEP-198 for server-to-server communication for ejabbere. Could anyone help me in getting started?

Holger Weiß

unread,
Mar 12, 2016, 1:36:20 PM3/12/16
to BEAM Community
* <sahilsha...@gmail.com> [2016-03-08 06:22]:
> I'd like to contribute to Beam community and interested in
> implementation of XEP-198 for server-to-server communication for
> ejabbere. Could anyone help me in getting started?

You'll obviously need a development environment to play around with
ejabberd. I usually create a dedicated user for that purpose and then
just install both Erlang and ejabberd into his home directory. As an
alternative, you could try the Vagrant/Ansible setup available on
GitHub.น

Regarding the actual project idea, I'd start with reading the stream
management extensionฒ and getting familiar with ejabberd's server-to-
server (s2s) code. ejabberd's client-to-server (c2s) implementation
already supports stream management, but you won't be able to reuse much
of the actual code, as the data structures and control flow are very
different for s2s connections. One difference is that there are
separate modules for incoming and outgoing s2s connections,
ejabberd_s2s_in and ejabberd_s2s_out. Most parts of XEP-0198 were
written with c2s connections in mind; i.e., the extension specifies how
clients and how servers should behave. For s2s connections, you'd
implement the server behavior in ejabberd_s2s_in, and the client
behavior in ejabberd_s2s_out. (ejabberd_c2s only implements the
server behavior.)

Apart from that, I'd also like to see ejabberd_s2s_out queue outgoing
data for some configurable number of seconds/minutes if the initial
connection attempt fails (because the remote server is rebooted or
whatever). This is a somewhat unrelated feature, as the queuing would
happen before stream management is negotiated (and therefore also for
remote servers that don't support XEP-0198). But you'd possibly
implement this feature with the same piece of code.

I hope this helps. If any of this is unclear, just ask :-)

Holger

https://github.com/processone/ejabberd-vagrant-dev
https://xmpp.org/extensions/xep-0198.html
Reply all
Reply to author
Forward
0 new messages