[ejabberd] add_ and delete_rosteritem throughput

David Laban alsuren at gmail.com
Mon May 20 17:33:29 MSK 2013


On Thursday 16 May 2013 17:50:15 Steven Lehrburger wrote:
> Hi David, thanks for the algorithm/questions. Answers below!
> 
> a.1) What are these roster pushes for?
> 
> I'm working on a chat product that feels more like real-life group social
> situations (office, conference, party, coffee shop, etc). Users can see the
> conversations their friends are having, but not what they're saying unless
> they join that conversation. I've built it on top of XMPP so that it works
> with existing clients, and this GIF shows the basics of what I've built so
> far: https://dashdash.com/static/img/screencast.gif.
> 
> The roster displays for the user the active conversations that s/he can
> see. I do a roster push when: a conversation starts, a conversation ends,
> or the participants in a conversation change. That push needs to go to the
> participants, as well as to each user who is a "friend" on the service of
> any of the participants, so it's a potentially large number.
> 
a.3) Why don't you just use MUCs for these conversations?
("join groupchat" ... prosody at conference.prosody.im
                   or jdev at conference.jabber.org
 in a competant IM client and you will see a workflow that looks very similar
 to the one you describe)

> b.1) How are they grouped?
> 
> Each user has one roster group of contacts, and one roster group of
> conversations. Contacts move from the former to the latter when a
> conversation becomes active (via a roster push), and vice versa when the
> conversation ends.
> 
>   b.3) Would something like http://www.ejabberd.im/shared-roster-all ?)
> 
> I've considered shared roster groups, but not recently. As I understand it,
> I'd need a shared roster group for every edge in the social graph + every
> active conversation, and that might not even work, since I need to set and
> change contact nicknames whenever the conversation state changes.
> 
b.3) Sounds suspiciciously like MUC room lists.

> f.1) Do you have control of the client software?
> 
> No - it works with Adium/Pidgin/etc. One day I'll write my own clients, but
> not yet :)

f.3) I assume that pidgin already supports MUCs

> 3) Where Could we be?
> 
> I could be modifying ejabberd itself instead of relying on a Python
> component, but have only a superficial knowledge of Erlang.
> 
Step 3) is the "let's list all of the possibilities" phase. Normally, answers 
to this question become obvious when you have gone over steps 1 and 2 
thoroughly.

> 4) Where Should we be?
> 
> I should probably write an XMPP server from scratch that has all of this
> weird custom group logic built in, but I don't have enough users to justify
> that amount of work yet.
> 
One step at a time. Get yourself a nice big list of possibilities for step 3 
and then we'll go from there.

David.


More information about the ejabberd mailing list