Abstract Chat Method

[richteer]

Major change, will also result in a major API revision.

Abstract away the method of chat, so that XMPP, IRC, etc can all be handled the same way.

[sjrct]

Maybe a class structure like this?

Message:
    content
    room
    reply(with) - probably equivalent to calling room.send
    sender

Room:
    name
    protocol - xmpp, irc, etc
    participants
    send(message)

User:
    name - fully qualified, e.g. jid of xmpp
    nick - short name (maybe per room?)
    is_admin

Seems to make sense to me for a rough structure. Not sure what other functionality is needed. Some presence stuff probably.

[richteer]

I almost want to make the messages just pure dictionary, and not even class-ify them. Sleek already kinda does that, so it might be beneficial to just leave them as is, that way modules can poke around in case there is something specific that's not covered (XMPP for example has a lot of extra crap that can be put into their stanzas, and just directly copying that over makes API writing minimal).

Secondly, sending is I think handled similarly between IRC and XMPP, so it might almost make sense to just have one send method, and the reply method would just reverse the from and to fields. I mean, XMPP conferences are just a set of jid's with a resource for each user.

This is where the abitrary storing of data into the message dicts might come in handy, since module writers can look for something like "type":"groupchat" or something.

Does any of this make sense? I've been thinking about it mostly in the shower, and haven't really formalized any thoughts yet.

[sjrct]

The only thing I would have against the arbitrary dictionary is that the assurance of where things are is lost, and therefore modules may have to do different things for different protocols, adding more complexity to the modules themselves. I understand the point that there is more information from some protocols and less from others, so perhaps there could be a dictionary called metadata or something akin to that on the message that stores arbitrary, protocol-specific data, while standard things like message content are stored on the message themselves.

I agree that there really should be one send method, the idea of a reply on the message object was just a convenient wrapper in my mind.

Also, I feel like having a type on the room object and then a room on the message is more sensible than just having a room-type on the message.