-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client roster support #41
Comments
I'm guessing this is a way to work around having to use group chat rooms, or is it to solve some other workflow? |
In our case it was definitely to avoid using chat rooms or XMPP MUCs. We couldn't get the entire staff to consistently keep any chat room open all the time; we needed something that was push and would also store history and push that as well when people were offline and missed messages. XMPP and OpenFire did everything we needed for that. The only weak link was keeping track of the user list. Originally we just added a basic persistence layer with redis, but it was kind of a pain. Just grabbing the XMPP roster made a lot more sense. |
One of the primary things we use Hubot for in our office is to support pure XMPP-based staff chat (essentially XMPP broadcast). In order to make that happen, I extended hubot-xmpp to pull down the client's default roster when it connects, which then gets stored in an array on the robot.
This allows for something like...
...so we get a lightweight broadcast system that relies only on XMPP.
That's a long way of saying, if I cleaned up my implementation and made a pull request, is this something you could see being in the core library? It may be possible to simply do this as a class that extends XmppBot, but I did this a while ago and pretty quick, so I'm not 100% sure. That may be ideal, though, if possible.
The text was updated successfully, but these errors were encountered: