Decouple xmpp code

[cburschka]

The cadence code base is kind of messy. It's nominally divided into modules (xmpp, ui, visual and "chat", which mostly handles user commands but is kind of a catch-all), but these modules are very tightly coupled.

The xmpp module's functionality could theoretically be stand-alone, as a sort of state+roster controller that wraps a Strophe connection.

This would require several things:

• remove all calls from xmpp to other modules. Instead, xmpp should implement its own event dispatcher that the application hooks into.
• remove xmpp's dependence on config. All the keys it uses should be passed to its init function.
• remove xmpp.room.active. the xmpp connection can be joined in any number of rooms, and only the UI cares which of them is the active context. This is required for the multi context feature.
• actually implement roster handling. Maintain a contact list and send service discovery (+caps protocol stuff) as needed.

More as I think of it.

[cburschka]

Theoretically, the connection should be able to join rooms on any conference server too.

[cburschka]

XMPP standalone module tentatively titled "Cadenza".

[cburschka]

1. One global "connection" object (because cross-domain websockets is too much of a hassle).
2. Any number of "conversation" objects. Each conversation is uniquely identified by a room, other user, or anything with a JID. (Bare JID, in this case.)
3. On the front end, "contexts". Contexts are navigated by tabs, and can be opened or closed. Conversations are attached to contexts, which means that the context captures and displays incoming traffic, and outgoing commands/messages in the context are sent to the attached conversation.
4. Conversations have states/types - offline, not joined, groupchat, chat, etc.
5. You can change rooms inside the same context, effectively replacing the attached conversation (same as in cadence 1.x)
6. Server messages are broadcast to multiple contexts (eg. the user's own domain broadcasts to all contexts, and other service domains to all contexts attached to a conversation on that service).

TO BE DETERMINED: Privmsg inside rooms.

1. Is this on the xmpp end, requiring a "virtual conversation object" that piggy-backs on a room and sends messages to a specific user / captures messages from that user? Violates some encapsulation.
2. Or is it on the front end, requiring the same conversation to be attached to multiple contexts, each of which captures particular incoming messages, and each of which sends outgoing messages either publically or to a particular target?
3. Or do we avoid this entirely, by displaying all private messages inside the same context, and requiring users to use direct messaging to use a separate tab?

[cburschka]

To fully support direct conversations, we also need a way to show the user's contact list (ie presence subscriptions).

There's no good place for that now - it shouldn't be confusable with the roster.

[sylae]

To fully support direct conversations, we also need a way to show the user's contact list (ie presence subscriptions).
There's no good place for that now - it shouldn't be confusable with the roster.

Perhaps another icon in the bottom icon dock (since we've inherited the use of the Tango icons from ajax-chat, why not x-office-address-book) that opens up a sidebar tab, listing the contacts. To further differentiate from the roster sidebar, perhaps include some vcard info/user avatar/etc with the contacts?

[cburschka]

It looks like most of the XMPP backend could be replaced with: https://github.com/strophe/strophejs-plugins/

There are plugins for XEP-0115 (Entity Caps, #317), XEP-0050 (MUC, all we do), XEP-0004 (data forms, #204), XEP-0085 (Chat States, #201), XEP-0030 (Service Discovery, #291), XEP-0049 (XML Storage, #261), XEP-0066 / XEP-0047 (OOB / IB data, #312 ), XEP-0199 (Ping, #150, #151),

What remains of the xmpp.js code would be some bridging code between UI and these plugins.

Next question: Why the hell didn't I look for this two years ago. ;_;