|Posted: Sun Oct 08, 2006 5:19 pm
|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
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
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
* 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
ejabberd mailing list
Post recived from mailinglist
|Back to top
All times are GMT
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum