[ejabberd] Entity Capabilities in ejabberd

Magnus Henoch mange at freemail.hu
Sun Oct 8 21:18:15 MSD 2006


I've slowly started hacking at PEP for ejabberd again.  (For those who
have missed it, it's here: <URL:http://www.dtek.chalmers.se/~henoch/te
xt/ejabberd-pep.html>)

As the new revision of the XEP uses Entity Capabilities (XEP-0115),
ejabberd would need to handle that.  I came up with the following
design; comments are very welcome.

* Gathering disco information

1. ejabberd_c2s receives available presence containing caps from a
   contact.  It stores the node, the version, and the extensions list
   in a dictionary in its state data, and notifies mod_caps about this
   triple (Node, Version, Extensions).

2. mod_caps checks whether Node++"#"++Version and [Node++"#"++Ext ||
   Ext <- Extensions] are in the Mnesia table mapping caps nodes to
   disco features.  If not, it sends disco requests to the contact.

   That is difficult, since ejabberd currently has no way of receiving
   IQ responses.  I started hacking support for that into the general
   IQ handling in ejabberd_local, but it struck me that since the
   handlers are in an ETS table, a process requiring an IQ response
   would have to register that on every node... maybe a separate
   Mnesia table for IQ responses would do?

3. mod_caps receives disco responses and enters information into the
   caps Mnesia table.

* Sending last item when a contact goes online

1. ejabberd_sm, upon receiving a presence packet, runs
   incoming_presence_hook.

2. mod_pubsub has a function in that hook.  It stores all presence in
   the pubsub_presence table, and from that information concludes
   whether the contact went from unavailable to available.  If so, it
   asks mod_caps for the types of notifications desired by the
   contact (using gen_server:call).

   Not sure about the pubsub_presence table; it feels like duplication
   of effort and information.

3. mod_caps doesn't return that information until it's available,
   i.e. when responses to disco requests have arrived, if necessary.
   This means that it could timeout (depending on the timeout limit
   specified by mod_pubsub).

4. mod_pubsub sends the last item of the nodes to which the contact is
   subscribed and for whose content the contact expresses interest
   through caps.

* Broadcasting a published item

1. The user publishes a new item to a PEP node.

2. mod_pubsub uses my new ejabberd_sm:get_session_pid function to find
   the pid of the ejabberd_c2s process that just sent the item, and
   uses my new ejabberd_c2s:get_subscribed_and_online function to find
   which contacts are subscribed to the users presence and available.

3. mod_pubsub further refines the set by asking mod_caps about which
   of these contacts are interested in the newly published content.
   By this time, we should have gathered all necessary disco
   information, but a timeout might occur nevertheless.

4. mod_pubsub sends the new item to the remaining contacts.


So, my questions:

 - Is my plan sane?  Does it use too much resources?  Are there better
   ways to do it?
 - How should ejabberd send IQ requests and handle responses to those
   requests?

-- 
Magnus
JID: legoscia at jabber.cd.chalmers.se



More information about the ejabberd mailing list