jadedctrl/Chat-O-Matic
jadedctrl/ Chat-O-Matic
1
0
Disbranĉigi 0
Fontkodo Issues 20 Tirpetoj Actions Packages Projects Eldonoj 2 Wiki Activity
Chat-O-Matic/application/Server.h

88 lines
2.2 KiB
C
Raw Normal View History

Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
/*
Update copyright year.
2011-12-03 16:38:03 -06:00
* Copyright 2009-2011, Andrea Anzani. All rights reserved.
* Copyright 2009-2011, Pier Luigi Fiorini. All rights reserved.
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
* Distributed under the terms of the MIT License.
*/
#ifndef _SERVER_H
#define _SERVER_H
#include <Message.h>
#include <MessageFilter.h>
Preferences dialog is progressing...
2010-05-08 14:35:28 -05:00
#include <libsupport/KeyMap.h>
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
#include "CayaConstants.h"
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
#include "ChatCommand.h"
Rename ContactLinker to Contact
2021-05-23 14:39:07 -05:00
#include "Contact.h"
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
#include "Conversation.h"
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers Previously, all Conversations/Contacts/Users were stored in the Server, each in their respective KeyMaps, identified solely by their identifiers. This leads to the glaring problem of overlap― if the user has multiple accounts, some users/rooms might be used or present in multiple accounts at the same time. Now, each accounts' Contacts, Conversations, and Users are stored in its ProtocolLooper, making this overlap impossible. An oversight of only allowing one user identifier to be stored (fMySelf) in Server was also fixed this way. This is the bulk of the work required for multi-account support― now, the user can join the same XMPP room on two seperate accounts, and it works perfectly.
2021-06-10 15:16:43 -05:00
#include "ProtocolLooper.h"
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
#include "User.h"
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
class CayaProtocol;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
class RosterItem;
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
class ProtocolLooper;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
typedef KeyMap<bigtime_t, ProtocolLooper*> ProtocolLoopers;
Create JoinWindow and protocol messages for joining rooms Protocol messages was added to the API to allow joining abstract rooms by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in anticipation of future room-related calls, some messages' values have been shifted. A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in the main window), to allow joining a room with this protocol message. The user can select which account the room should be joined from through a drop-down menu in the lower left-hand corner― a design I think could be replicated in other parts of Caya well. Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and SetAddOnPath() respectively. GetName() and SetName() were also added, where "name" is the account name (aka the leaf of the protocols settings path). To Server, a new KeyMap was added for convenience (AccountInstances), to associate these account names with their instance IDs.
2021-06-01 21:43:19 -05:00
typedef KeyMap<BString, bigtime_t> AccountInstances;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
class Server: public BMessageFilter {
public:
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
Server();
Add own user to conversations' user lists Really, only one line changed in _EnsureConversation()― the rest is re-organizing the file.
2021-05-31 13:04:58 -05:00
void Quit();
void LoginAll();
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
virtual filter_result Filter(BMessage* message, BHandler** target);
filter_result ImMessage(BMessage* msg);
Some style violations fixed.
2010-05-20 16:31:55 -05:00
void AddProtocolLooper(bigtime_t instanceId,
CayaProtocol* cayap);
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
void RemoveProtocolLooper(bigtime_t instanceId);
Create JoinWindow and protocol messages for joining rooms Protocol messages was added to the API to allow joining abstract rooms by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in anticipation of future room-related calls, some messages' values have been shifted. A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in the main window), to allow joining a room with this protocol message. The user can select which account the room should be joined from through a drop-down menu in the lower left-hand corner― a design I think could be replicated in other parts of Caya well. Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and SetAddOnPath() respectively. GetName() and SetName() were also added, where "name" is the account name (aka the leaf of the protocols settings path). To Server, a new KeyMap was added for convenience (AccountInstances), to associate these account names with their instance IDs.
2021-06-01 21:43:19 -05:00
ProtocolLooper* GetProtocolLooper(bigtime_t instanceId);
AccountInstances
GetAccounts();
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
void SendProtocolMessage(BMessage* msg);
Merged multiprotocol branch with trunk.
2010-05-16 16:02:50 -05:00
void SendAllProtocolMessage(BMessage* msg);
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
RosterMap Contacts() const;
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers Previously, all Conversations/Contacts/Users were stored in the Server, each in their respective KeyMaps, identified solely by their identifiers. This leads to the glaring problem of overlap― if the user has multiple accounts, some users/rooms might be used or present in multiple accounts at the same time. Now, each accounts' Contacts, Conversations, and Users are stored in its ProtocolLooper, making this overlap impossible. An oversight of only allowing one user identifier to be stored (fMySelf) in Server was also fixed this way. This is the bulk of the work required for multi-account support― now, the user can join the same XMPP room on two seperate accounts, and it works perfectly.
2021-06-10 15:16:43 -05:00
Contact* ContactById(BString id, int64 instance);
void AddContact(Contact* contact, int64 instance);
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
UserMap Users() const;
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers Previously, all Conversations/Contacts/Users were stored in the Server, each in their respective KeyMaps, identified solely by their identifiers. This leads to the glaring problem of overlap― if the user has multiple accounts, some users/rooms might be used or present in multiple accounts at the same time. Now, each accounts' Contacts, Conversations, and Users are stored in its ProtocolLooper, making this overlap impossible. An oversight of only allowing one user identifier to be stored (fMySelf) in Server was also fixed this way. This is the bulk of the work required for multi-account support― now, the user can join the same XMPP room on two seperate accounts, and it works perfectly.
2021-06-10 15:16:43 -05:00
User* UserById(BString id, int64 instance);
void AddUser(User* user, int64 instance);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
ChatMap Conversations() const;
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers Previously, all Conversations/Contacts/Users were stored in the Server, each in their respective KeyMaps, identified solely by their identifiers. This leads to the glaring problem of overlap― if the user has multiple accounts, some users/rooms might be used or present in multiple accounts at the same time. Now, each accounts' Contacts, Conversations, and Users are stored in its ProtocolLooper, making this overlap impossible. An oversight of only allowing one user identifier to be stored (fMySelf) in Server was also fixed this way. This is the bulk of the work required for multi-account support― now, the user can join the same XMPP room on two seperate accounts, and it works perfectly.
2021-06-10 15:16:43 -05:00
Conversation* ConversationById(BString id, int64 instance);
void AddConversation(Conversation* chat, int64 instance);
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
CommandMap Commands();
ChatCommand* CommandById(BString id);
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
private:
Added a new deskbar replicant with related classes and icons, disabled libdownload and curl depencency, fixed some warnings and style violations around the code
2011-12-14 17:36:27 -06:00
ProtocolLooper* _LooperFromMessage(BMessage* message);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
Contact* _EnsureContact(BMessage* message);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
User* _EnsureUser(BMessage* message);
Receive lists and changes in room participants from protocols Two new messages were added to the protocol API to do this: M_ROOM_PARTICIPANTS, which can be used when someone joins a room, or on joining a room to send a full list of users, and IM_ROOM_PARTICIPANT_LEFT, for when a user has left the room/disconnected. IM_SET_STATUS no longer assumes received data comes from contacts, but any general user. UserItem was made to reflect changes in the User's name. Chat messages can now be reliably received in a given room. :)
2021-06-02 16:53:03 -05:00
User* _EnsureUser(BString id, ProtocolLooper* protoLooper);
Create Conversation class, use it instead of Contact for chats This is a commit with it's foot in a lot of places, but: The Conversation class was created as the abstraction of chats: All ImMessages that are relevant to a conversation get routed through it, meta-data on chats is stored in it (even if right now that's basically limited to the user list and ID). Server was given more methods to help accessing contacts― ContactById(BString) and AddContact(Contact*). This better allows Conversations to add and fetch Contacts as necessary. Right now, all users in chats are treated as Contacts, so in the future creating an independent userlist for Server (fUserMap?) would be useful. Server also now stores all Conversations (fChatMap) and has some convenience methods like for Contacts: Conversations(), ConversationById(BString), and AddConversation(Conversation*). CayaRenderView has been changed to not store user nicks, and will use the appropriate nick of any arbitrarily-numbered user. Users also have a map of all Conversations they are a part of (fChatMap). The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
Conversation* _EnsureConversation(BMessage* message);
Use 'User' over 'Contact' where appropriate
2021-05-31 11:56:45 -05:00
Support for "Roles" (user, moderator, admin, etc.) Add scaffodling support for arbitrary roles and permission-based (and varying!) UI. A new class, Role, represents a user's role in a given room, with three values: * The role's title * The role's permission-set * The role's priority The permission set is a bitmask value for various permissions (e.g., PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy. A user with higher priority (and PERM_BAN) can ban a user with lower priority, but not vice-versa. Two users with the same priority can't ban/kick/mute each other, etc. These permissions should be used to determine what UI elements are displayed― if the user doesn't have permission to ban users, then a "Ban" button shouldn't exist. If the user is muted, they shouldn't be able to type. So on and so forth. For now, permissions are sent with a IM_ROLECHANGE message and stored by the Conversation, but aren't really in use yet. This system should be flexible groundwork to account for the varying administrative hierarchies and norms of different protocols.
2021-06-06 00:41:45 -05:00
Role* _GetRole(BMessage* msg);
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
void _InitDefaultCommands();
Added a new deskbar replicant with related classes and icons, disabled libdownload and curl depencency, fixed some warnings and style violations around the code
2011-12-14 17:36:27 -06:00
void _ReplicantStatusNotify(CayaStatus status);
ProtocolLoopers fLoopers;
Create JoinWindow and protocol messages for joining rooms Protocol messages was added to the API to allow joining abstract rooms by their chat_id― IM_JOIN_ROOM and IM_ROOM_JOINED. To make room in anticipation of future room-related calls, some messages' values have been shifted. A JoinWindow was created (found through [Chat→Join Room] or [Alt-J] in the main window), to allow joining a room with this protocol message. The user can select which account the room should be joined from through a drop-down menu in the lower left-hand corner― a design I think could be replicated in other parts of Caya well. Path() and SetPath() in CayaProtocol were renamed to AddOnPath() and SetAddOnPath() respectively. GetName() and SetName() were also added, where "name" is the account name (aka the leaf of the protocols settings path). To Server, a new KeyMap was added for convenience (AccountInstances), to associate these account names with their instance IDs.
2021-06-01 21:43:19 -05:00
AccountInstances
fAccounts;
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
CommandMap fCommands;
Add own user to conversations' user lists Really, only one line changed in _EnsureConversation()― the rest is re-organizing the file.
2021-05-31 13:04:58 -05:00
BString fMySelf;
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
};
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00
Usual SVN tree (branches, tags, trunk).
2010-05-07 04:47:10 -05:00
#endif // _SERVER_H
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00