2010-05-07 04:47:10 -05:00
|
|
|
/*
|
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.
|
2021-06-15 21:05:21 -05:00
|
|
|
* Copyright 2021, Jaidyn Levesque. All rights reserved.
|
2010-05-07 04:47:10 -05:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
|
*
|
|
|
|
|
* Authors:
|
|
|
|
|
* Andrea Anzani, andrea.anzani@gmail.com
|
|
|
|
|
* Pier Luigi Fiorini, pierluigi.fiorini@gmail.com
|
2021-06-15 21:05:21 -05:00
|
|
|
* Jaidyn Levesque, jadedctrl@teknik.io
|
2011-12-14 17:36:27 -06:00
|
|
|
*
|
|
|
|
|
* Contributors:
|
|
|
|
|
* Dario Casalinuovo
|
2010-05-07 04:47:10 -05:00
|
|
|
*/
|
|
|
|
|
|
2021-06-15 21:05:21 -05:00
|
|
|
#include "Server.h"
|
|
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Application.h>
|
2021-07-19 09:54:27 -05:00
|
|
|
#include <Catalog.h>
|
2010-05-16 16:02:50 -05:00
|
|
|
#include <Debug.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Entry.h>
|
2010-05-30 07:17:32 -05:00
|
|
|
#include <Notification.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <Path.h>
|
2021-06-02 16:53:03 -05:00
|
|
|
#include <StringList.h>
|
2010-05-07 04:47:10 -05:00
|
|
|
#include <TranslationUtils.h>
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
#include "Account.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "AccountManager.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "AppMessages.h"
|
2021-06-22 01:06:00 -05:00
|
|
|
#include "Cardie.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "ChatProtocol.h"
|
|
|
|
|
#include "AppPreferences.h"
|
|
|
|
|
#include "ChatProtocolMessages.h"
|
2021-06-30 14:27:58 -05:00
|
|
|
#include "Flags.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "ImageCache.h"
|
2021-06-08 15:32:04 -05:00
|
|
|
#include "InviteDialogue.h"
|
|
|
|
|
#include "ProtocolLooper.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
#include "ProtocolManager.h"
|
|
|
|
|
#include "RosterItem.h"
|
2021-06-15 21:05:21 -05:00
|
|
|
#include "UserInfoWindow.h"
|
2021-06-20 12:44:20 -05:00
|
|
|
#include "Utils.h"
|
2010-05-07 04:47:10 -05:00
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
#undef B_TRANSLATION_CONTEXT
|
|
|
|
|
#define B_TRANSLATION_CONTEXT "Server"
|
|
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
Server::Server()
|
2010-05-19 17:28:26 -05:00
|
|
|
:
|
2021-06-30 14:27:58 -05:00
|
|
|
BMessageFilter(B_ANY_DELIVERY, B_ANY_SOURCE)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-06-30 14:27:58 -05:00
|
|
|
if (fChatItems.IsEmpty() == false || fUserItems.IsEmpty() == false
|
|
|
|
|
|| fCommands.CountItems() > 0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
BResources* res = ChatResources();
|
|
|
|
|
|
|
|
|
|
// Loading user pop-up items
|
|
|
|
|
for (int i = 0; i < 6; i++) {
|
|
|
|
|
size_t size;
|
|
|
|
|
BMessage temp;
|
|
|
|
|
const void* buff = res->LoadResource(B_MESSAGE_TYPE, 1100 + i, &size);
|
|
|
|
|
temp.Unflatten((const char*)buff);
|
|
|
|
|
fUserItems.AddItem(new BMessage(temp));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Loading room pop-up items
|
|
|
|
|
BMessage leave;
|
|
|
|
|
size_t leaveSize;
|
|
|
|
|
const void* leaveBuff = res->LoadResource(B_MESSAGE_TYPE, 1120, &leaveSize);
|
|
|
|
|
leave.Unflatten((const char*)leaveBuff);
|
|
|
|
|
fChatItems.AddItem(new BMessage(leave));
|
|
|
|
|
|
|
|
|
|
// Loading default chat commands
|
|
|
|
|
for (int i = 0; i < 9; i++) {
|
|
|
|
|
size_t size;
|
|
|
|
|
BMessage temp;
|
|
|
|
|
const void* buff = res->LoadResource(B_MESSAGE_TYPE, 1140 + i, &size);
|
|
|
|
|
temp.Unflatten((const char*)buff);
|
|
|
|
|
ChatCommand* cmd = new ChatCommand(&temp);
|
2021-06-20 01:24:34 -05:00
|
|
|
fCommands.AddItem(cmd->GetName(), cmd);
|
|
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-05-19 17:28:26 -05:00
|
|
|
void
|
2010-05-07 04:47:10 -05:00
|
|
|
Server::Quit()
|
|
|
|
|
{
|
2021-06-12 21:42:10 -05:00
|
|
|
for (int i = 0; i < fLoopers.CountItems(); i++)
|
|
|
|
|
RemoveProtocolLooper(fLoopers.KeyAt(i));
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
void
|
|
|
|
|
Server::LoginAll()
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
for (uint32 i = 0; i < fLoopers.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueAt(i);
|
|
|
|
|
|
|
|
|
|
BMessage* msg = new BMessage(IM_MESSAGE);
|
2010-05-19 15:37:26 -05:00
|
|
|
msg->AddInt32("im_what", IM_SET_OWN_STATUS);
|
2021-06-20 12:44:20 -05:00
|
|
|
msg->AddInt32("status", STATUS_ONLINE);
|
2010-05-16 16:02:50 -05:00
|
|
|
looper->PostMessage(msg);
|
|
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
filter_result
|
|
|
|
|
Server::Filter(BMessage* message, BHandler **target)
|
|
|
|
|
{
|
|
|
|
|
filter_result result = B_DISPATCH_MESSAGE;
|
|
|
|
|
|
2010-05-19 17:28:26 -05:00
|
|
|
switch (message->what) {
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
case IM_MESSAGE:
|
|
|
|
|
result = ImMessage(message);
|
|
|
|
|
break;
|
|
|
|
|
case IM_ERROR:
|
|
|
|
|
ImError(message);
|
|
|
|
|
break;
|
2021-06-20 12:44:20 -05:00
|
|
|
case APP_CLOSE_CHAT_WINDOW:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
BString id = message->FindString("chat_id");
|
2010-05-16 16:02:50 -05:00
|
|
|
if (id.Length() > 0) {
|
2010-05-07 04:47:10 -05:00
|
|
|
bool found = false;
|
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* item = fChatMap.ValueFor(id, &found);
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
case APP_ACCOUNT_DISABLED:
|
|
|
|
|
{
|
|
|
|
|
BString name;
|
|
|
|
|
int64 instance;
|
|
|
|
|
if (message->FindInt64("instance", &instance) != B_OK)
|
|
|
|
|
return result;
|
|
|
|
|
|
|
|
|
|
// "Whoops" notification
|
|
|
|
|
if (AppPreferences::Item()->NotifyProtocolStatus == true
|
|
|
|
|
&& message->FindString("name", &name) == B_OK) {
|
|
|
|
|
BBitmap* icon = new BBitmap(message);
|
2021-07-19 09:54:27 -05:00
|
|
|
BString content(B_TRANSLATE("%user% has been disabled!"));
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
content.ReplaceAll("%user%", name);
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
_SendNotification(B_TRANSLATE("Disabled"), content, icon);
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
}
|
2021-07-18 15:39:30 -05:00
|
|
|
break;
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
}
|
2021-06-20 12:44:20 -05:00
|
|
|
case APP_REPLICANT_MESSENGER:
|
2011-12-14 17:36:27 -06:00
|
|
|
{
|
2012-02-27 18:46:15 -06:00
|
|
|
BMessenger* messenger = new BMessenger();
|
2011-12-14 17:36:27 -06:00
|
|
|
|
|
|
|
|
status_t ret = message->FindMessenger(
|
2012-02-27 18:46:15 -06:00
|
|
|
"messenger", messenger);
|
2011-12-14 17:36:27 -06:00
|
|
|
|
2012-02-27 18:46:15 -06:00
|
|
|
if (ret != B_OK || !messenger->IsValid()) {
|
2011-12-14 17:36:27 -06:00
|
|
|
printf("err %s\n", strerror(ret));
|
2012-02-27 18:46:15 -06:00
|
|
|
break;
|
2011-12-14 17:36:27 -06:00
|
|
|
}
|
2012-02-27 18:46:15 -06:00
|
|
|
AccountManager* accountManager = AccountManager::Get();
|
|
|
|
|
accountManager->SetReplicantMessenger(messenger);
|
2012-03-03 20:27:16 -06:00
|
|
|
accountManager->ReplicantStatusNotify(accountManager->Status());
|
2011-12-14 17:36:27 -06:00
|
|
|
break;
|
|
|
|
|
}
|
2021-06-20 12:44:20 -05:00
|
|
|
case APP_USER_INFO:
|
2021-06-15 21:05:21 -05:00
|
|
|
{
|
|
|
|
|
User* user = _EnsureUser(message);
|
|
|
|
|
if (user != NULL) {
|
|
|
|
|
UserInfoWindow* win = new UserInfoWindow(user);
|
|
|
|
|
win->Show();
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-20 12:44:20 -05:00
|
|
|
case APP_REQUEST_HELP:
|
2021-06-15 00:45:51 -05:00
|
|
|
{
|
|
|
|
|
BString body;
|
|
|
|
|
BString cmd_name = message->FindString("misc_str");
|
2021-06-15 00:59:00 -05:00
|
|
|
int64 instance = message->FindInt64("instance");
|
2021-06-15 00:45:51 -05:00
|
|
|
Conversation* chat = _EnsureConversation(message);
|
|
|
|
|
|
|
|
|
|
if (chat == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
if (cmd_name.IsEmpty() == false) {
|
2021-06-15 00:59:00 -05:00
|
|
|
ChatCommand* cmd = CommandById(cmd_name, instance);
|
2021-06-15 00:45:51 -05:00
|
|
|
if (cmd == NULL)
|
2021-07-19 09:54:27 -05:00
|
|
|
body = B_TRANSLATE("-- That command doesn't exist. Try "
|
|
|
|
|
"'/help' for a list.\n");
|
2021-06-15 00:45:51 -05:00
|
|
|
else {
|
|
|
|
|
body = "** ";
|
|
|
|
|
body << cmd->GetName() << " ― " << cmd->GetDesc() << "\n";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
2021-06-15 14:40:28 -05:00
|
|
|
CommandMap combinedCmds;
|
|
|
|
|
combinedCmds.AddList(fCommands);
|
|
|
|
|
combinedCmds.AddList(chat->GetProtocolLooper()->Commands());
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
body << B_TRANSLATE("** Commands: ");
|
2021-06-15 14:40:28 -05:00
|
|
|
for (int i = 0; i < combinedCmds.CountItems(); i++) {
|
|
|
|
|
ChatCommand* cmd = combinedCmds.ValueAt(i);
|
2021-06-15 00:45:51 -05:00
|
|
|
if (i > 0) body << ", ";
|
|
|
|
|
body << cmd->GetName();
|
|
|
|
|
}
|
|
|
|
|
body << "\n";
|
|
|
|
|
}
|
|
|
|
|
BMessage* help = new BMessage(IM_MESSAGE);
|
|
|
|
|
help->AddInt32("im_what", IM_MESSAGE_RECEIVED);
|
|
|
|
|
help->AddString("body", body);
|
|
|
|
|
help->AddInt64("when", 0);
|
|
|
|
|
chat->ImMessage(help);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-05-16 16:02:50 -05:00
|
|
|
default:
|
|
|
|
|
// Dispatch not handled messages to main window
|
|
|
|
|
break;
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
2010-05-28 17:38:16 -05:00
|
|
|
return result;
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
filter_result
|
|
|
|
|
Server::ImMessage(BMessage* msg)
|
2010-05-28 17:38:16 -05:00
|
|
|
{
|
2010-05-07 04:47:10 -05:00
|
|
|
filter_result result = B_DISPATCH_MESSAGE;
|
|
|
|
|
int32 im_what = msg->FindInt32("im_what");
|
|
|
|
|
|
|
|
|
|
switch (im_what) {
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_CONTACT_LIST:
|
|
|
|
|
{
|
|
|
|
|
int i = 0;
|
|
|
|
|
BString id;
|
2021-05-31 13:04:58 -05:00
|
|
|
while (msg->FindString("user_id", i++, &id) == B_OK)
|
|
|
|
|
_EnsureContact(msg);
|
2010-05-19 15:37:26 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-19 22:37:20 -05:00
|
|
|
case IM_CONTACT_LIST_CONTACT_REMOVED:
|
|
|
|
|
{
|
|
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
|
|
if (looper == NULL || contact == NULL) {
|
|
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
looper->RemoveContact(contact);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_OWN_STATUS_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
|
int32 status;
|
|
|
|
|
const char* protocol;
|
|
|
|
|
if (msg->FindInt32("status", &status) != B_OK)
|
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
if (msg->FindString("protocol", &protocol) != B_OK)
|
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
|
|
|
|
|
AccountManager* accountManager = AccountManager::Get();
|
2021-06-20 12:44:20 -05:00
|
|
|
accountManager->SetStatus((UserStatus)status);
|
2011-12-14 17:36:27 -06:00
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_STATUS_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
|
|
|
|
int32 status;
|
|
|
|
|
|
|
|
|
|
if (msg->FindInt32("status", &status) != B_OK)
|
|
|
|
|
return B_SKIP_MESSAGE;
|
|
|
|
|
|
2021-06-02 16:53:03 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
|
if (!user)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
|
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
user->SetNotifyStatus((UserStatus)status);
|
2012-03-07 18:47:00 -06:00
|
|
|
BString statusMsg;
|
|
|
|
|
if (msg->FindString("message", &statusMsg) == B_OK) {
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetNotifyPersonalStatus(statusMsg);
|
2012-03-07 18:47:00 -06:00
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-05-31 13:04:58 -05:00
|
|
|
case IM_OWN_CONTACT_INFO:
|
|
|
|
|
{
|
2021-07-06 14:46:28 -05:00
|
|
|
BString id = msg->FindString("user_id");
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
if (looper == NULL || id.IsEmpty() == true) break;
|
|
|
|
|
|
|
|
|
|
Contact* contact = looper->GetOwnContact();
|
|
|
|
|
if (contact == NULL) {
|
|
|
|
|
contact = new Contact(id, Looper());
|
|
|
|
|
contact->SetProtocolLooper(looper);
|
|
|
|
|
looper->SetOwnContact(contact);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
2021-07-06 14:46:28 -05:00
|
|
|
|
2021-06-21 02:32:49 -05:00
|
|
|
BString name;
|
|
|
|
|
if (msg->FindString("user_name", &name) == B_OK)
|
|
|
|
|
contact->SetNotifyName(name);
|
2021-05-31 13:04:58 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_CONTACT_INFO:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
|
if (!contact)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-16 16:02:50 -05:00
|
|
|
|
2010-05-19 12:11:22 -05:00
|
|
|
const char* name = NULL;
|
|
|
|
|
|
2021-06-07 11:45:30 -05:00
|
|
|
if ((msg->FindString("user_name", &name) == B_OK)
|
2010-05-28 16:31:53 -05:00
|
|
|
&& (strcmp(name, "") != 0))
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyName(name);
|
2012-03-07 13:22:09 -06:00
|
|
|
|
|
|
|
|
BString status;
|
2021-06-07 00:03:15 -05:00
|
|
|
if (msg->FindString("message", &status) == B_OK)
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyPersonalStatus(status);
|
2010-05-28 16:31:53 -05:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IM_EXTENDED_CONTACT_INFO:
|
|
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Contact* contact = _EnsureContact(msg);
|
|
|
|
|
if (!contact)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-28 16:31:53 -05:00
|
|
|
|
2021-05-24 01:47:21 -05:00
|
|
|
if (contact->GetName().Length() > 0)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
2010-05-28 16:31:53 -05:00
|
|
|
|
|
|
|
|
const char* name = NULL;
|
|
|
|
|
|
2021-06-07 11:45:30 -05:00
|
|
|
if ((msg->FindString("full_name", &name) == B_OK)
|
2010-05-28 16:31:53 -05:00
|
|
|
&& (strcmp(name, "") != 0))
|
2021-05-24 01:47:21 -05:00
|
|
|
contact->SetNotifyName(name);
|
2021-06-07 11:45:30 -05:00
|
|
|
else if ((msg->FindString("user_name", &name) == B_OK)
|
|
|
|
|
&& (strcmp(name, "") != 0))
|
|
|
|
|
contact->SetNotifyName(name);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-07-13 14:43:48 -05:00
|
|
|
case IM_OWN_AVATAR_SET:
|
|
|
|
|
{
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
Contact* contact = looper->GetOwnContact();
|
|
|
|
|
entry_ref ref;
|
|
|
|
|
|
|
|
|
|
if (msg->FindRef("ref", &ref) == B_OK) {
|
|
|
|
|
BBitmap* bitmap = BTranslationUtils::GetBitmap(&ref);
|
|
|
|
|
if (bitmap != NULL)
|
|
|
|
|
contact->SetNotifyAvatarBitmap(bitmap);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-05-19 15:37:26 -05:00
|
|
|
case IM_AVATAR_SET:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-05-31 11:56:45 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
|
if (!user)
|
2010-05-29 23:28:04 -05:00
|
|
|
break;
|
|
|
|
|
|
2010-05-07 04:47:10 -05:00
|
|
|
entry_ref ref;
|
2010-05-29 23:28:04 -05:00
|
|
|
|
|
|
|
|
if (msg->FindRef("ref", &ref) == B_OK) {
|
|
|
|
|
BBitmap* bitmap = BTranslationUtils::GetBitmap(&ref);
|
2021-05-31 11:56:45 -05:00
|
|
|
user->SetNotifyAvatarBitmap(bitmap);
|
2010-05-29 23:28:04 -05:00
|
|
|
} else
|
2021-05-31 11:56:45 -05:00
|
|
|
user->SetNotifyAvatarBitmap(NULL);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-05-26 07:48:25 -05:00
|
|
|
case IM_CREATE_CHAT:
|
|
|
|
|
{
|
|
|
|
|
BString user_id = msg->FindString("user_id");
|
|
|
|
|
if (user_id.IsEmpty() == false) {
|
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* user = ContactById(user_id, msg->FindInt64("instance"));
|
2021-05-26 07:48:25 -05:00
|
|
|
user->GetProtocolLooper()->PostMessage(msg);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
case IM_CHAT_CREATED:
|
|
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
2021-05-31 11:56:45 -05:00
|
|
|
User* user = _EnsureUser(msg);
|
2021-05-26 07:48:25 -05:00
|
|
|
|
|
|
|
|
if (chat != NULL && user != NULL) {
|
|
|
|
|
chat->AddUser(user);
|
2021-05-28 22:26:32 -05:00
|
|
|
chat->ShowView(false, true);
|
2021-05-26 07:48:25 -05:00
|
|
|
}
|
2021-05-27 11:15:30 -05:00
|
|
|
|
2021-05-26 07:48:25 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-06-01 21:43:19 -05:00
|
|
|
case IM_JOIN_ROOM:
|
|
|
|
|
{
|
|
|
|
|
SendProtocolMessage(msg);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-18 01:30:59 -05:00
|
|
|
case IM_ROOM_CREATED:
|
2021-06-01 21:43:19 -05:00
|
|
|
case IM_ROOM_JOINED:
|
|
|
|
|
{
|
2021-06-18 01:39:34 -05:00
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
if (chat != NULL)
|
|
|
|
|
chat->ImMessage(msg);
|
2021-06-01 21:43:19 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-06-02 16:53:03 -05:00
|
|
|
case IM_ROOM_PARTICIPANTS:
|
|
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
BStringList ids;
|
|
|
|
|
BStringList name;
|
|
|
|
|
|
|
|
|
|
msg->FindStrings("user_name", &name);
|
|
|
|
|
if (msg->FindStrings("user_id", &ids) != B_OK)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
ProtocolLooper* protoLooper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < ids.CountStrings(); i++) {
|
|
|
|
|
User* user = _EnsureUser(ids.StringAt(i), protoLooper);
|
|
|
|
|
|
2021-06-29 15:19:43 -05:00
|
|
|
if (name.CountStrings() >= i && !name.StringAt(i).IsEmpty())
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetNotifyName(name.StringAt(i));
|
|
|
|
|
chat->AddUser(user);
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-07 00:03:15 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_JOINED:
|
2021-06-02 16:53:03 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_LEFT:
|
2021-06-07 00:03:15 -05:00
|
|
|
case IM_ROOM_PARTICIPANT_BANNED:
|
|
|
|
|
case IM_ROOM_PARTICIPANT_KICKED:
|
2021-06-02 16:53:03 -05:00
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
2021-06-07 00:03:15 -05:00
|
|
|
if (chat == NULL)
|
2021-06-02 16:53:03 -05:00
|
|
|
break;
|
2021-06-07 00:03:15 -05:00
|
|
|
chat->ImMessage(msg);
|
2021-06-02 16:53:03 -05:00
|
|
|
break;
|
2021-06-04 13:57:04 -05:00
|
|
|
}
|
2021-06-13 01:16:30 -05:00
|
|
|
case IM_ROOM_METADATA:
|
|
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
if (chat != NULL)
|
|
|
|
|
chat->ImMessage(msg);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_ROLECHANGED:
|
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
|
|
|
{
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
BString user_id;
|
|
|
|
|
Role* role = _GetRole(msg);
|
|
|
|
|
|
|
|
|
|
if (chat == NULL || msg->FindString("user_id", &user_id) != B_OK
|
|
|
|
|
|| role == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
chat->SetRole(user_id, role);
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_NAME_SET:
|
2021-06-06 18:06:46 -05:00
|
|
|
{
|
|
|
|
|
BString name;
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
if (msg->FindString("chat_name", &name) != B_OK || chat == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
chat->SetNotifyName(name.String());
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-07 11:45:30 -05:00
|
|
|
case IM_ROOM_SUBJECT_SET:
|
2021-06-04 13:57:04 -05:00
|
|
|
{
|
|
|
|
|
BString subject;
|
|
|
|
|
Conversation* chat = _EnsureConversation(msg);
|
|
|
|
|
if (msg->FindString("subject", &subject) != B_OK || chat == NULL)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
chat->SetNotifySubject(subject.String());
|
|
|
|
|
break;
|
2021-06-02 16:53:03 -05:00
|
|
|
}
|
2012-03-11 10:11:29 -05:00
|
|
|
case IM_SEND_MESSAGE:
|
|
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
// Route this message through the appropriate ProtocolLooper
|
2021-05-24 01:47:21 -05:00
|
|
|
Conversation* conversation = _EnsureConversation(msg);
|
|
|
|
|
if (conversation->GetProtocolLooper())
|
|
|
|
|
conversation->GetProtocolLooper()->PostMessage(msg);
|
2010-05-07 04:47:10 -05:00
|
|
|
break;
|
2010-05-16 16:02:50 -05:00
|
|
|
}
|
2021-05-30 19:07:50 -05:00
|
|
|
case IM_MESSAGE_SENT:
|
2010-05-07 04:47:10 -05:00
|
|
|
case IM_MESSAGE_RECEIVED:
|
2012-03-08 18:35:02 -06:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
Conversation* item = _EnsureConversation(msg);
|
|
|
|
|
item->ImMessage(msg);
|
2012-03-08 18:35:02 -06:00
|
|
|
break;
|
|
|
|
|
}
|
2021-06-08 15:32:04 -05:00
|
|
|
case IM_ROOM_INVITE_RECEIVED:
|
|
|
|
|
{
|
|
|
|
|
BString chat_id;
|
|
|
|
|
User* user = _EnsureUser(msg);
|
|
|
|
|
BString user_id = msg->FindString("user_id");
|
|
|
|
|
BString user_name = user_id;
|
|
|
|
|
BString chat_name = msg->FindString("chat_name");
|
|
|
|
|
BString body = msg->FindString("body");
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
|
|
if (msg->FindString("chat_id", &chat_id) != B_OK || looper == NULL)
|
2021-06-08 19:59:22 -05:00
|
|
|
{
|
2021-06-08 15:32:04 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (chat_name.IsEmpty() == true)
|
|
|
|
|
chat_name = chat_id;
|
|
|
|
|
|
|
|
|
|
if (user != NULL)
|
|
|
|
|
user_name = user->GetName();
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
BString alertBody(B_TRANSLATE("You've been invited to %room%."));
|
2021-06-08 15:32:04 -05:00
|
|
|
if (user_id.IsEmpty() == false)
|
2021-07-19 09:54:27 -05:00
|
|
|
alertBody = B_TRANSLATE("%user% has invited you to %room%.");
|
2021-06-08 15:32:04 -05:00
|
|
|
if (body.IsEmpty() == false)
|
|
|
|
|
alertBody << "\n\n\"%body%\"";
|
|
|
|
|
|
|
|
|
|
alertBody.ReplaceAll("%user%", user_name);
|
|
|
|
|
alertBody.ReplaceAll("%room%", chat_name);
|
|
|
|
|
alertBody.ReplaceAll("%body%", body);
|
|
|
|
|
|
2021-06-08 19:59:22 -05:00
|
|
|
BMessage* accept = new BMessage(IM_MESSAGE);
|
|
|
|
|
accept->AddInt32("im_what", IM_ROOM_INVITE_ACCEPT);
|
2021-06-08 15:32:04 -05:00
|
|
|
accept->AddString("chat_id", chat_id);
|
2021-06-08 19:59:22 -05:00
|
|
|
BMessage* reject = new BMessage(IM_MESSAGE);
|
|
|
|
|
accept->AddInt32("im_what", IM_ROOM_INVITE_REFUSE);
|
2021-06-08 15:32:04 -05:00
|
|
|
reject->AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
|
|
InviteDialogue* invite = new InviteDialogue(BMessenger(looper),
|
2021-07-19 09:54:27 -05:00
|
|
|
B_TRANSLATE("Invitation received"),
|
2021-06-08 15:32:04 -05:00
|
|
|
alertBody.String(), accept, reject);
|
|
|
|
|
invite->Go();
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-07 13:19:58 -05:00
|
|
|
case IM_USER_STARTED_TYPING:
|
|
|
|
|
case IM_USER_STOPPED_TYPING:
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2021-06-08 15:32:04 -05:00
|
|
|
// User* user = _EnsureUser();
|
|
|
|
|
// Conversation* chat = _EnsureConversation();
|
2010-05-07 04:47:10 -05:00
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
2010-05-30 07:17:32 -05:00
|
|
|
case IM_PROGRESS:
|
|
|
|
|
{
|
2021-07-18 15:39:30 -05:00
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
2010-05-30 07:17:32 -05:00
|
|
|
const char* protocol = NULL;
|
|
|
|
|
const char* title = NULL;
|
|
|
|
|
const char* message = NULL;
|
|
|
|
|
float progress = 0.0f;
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
if (looper == NULL)
|
2010-05-30 07:17:32 -05:00
|
|
|
return result;
|
|
|
|
|
if (msg->FindString("title", &title) != B_OK)
|
|
|
|
|
return result;
|
|
|
|
|
if (msg->FindString("message", &message) != B_OK)
|
|
|
|
|
return result;
|
|
|
|
|
if (msg->FindFloat("progress", &progress) != B_OK)
|
|
|
|
|
return result;
|
2012-03-08 16:55:13 -06:00
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
if (!AppPreferences::Item()->NotifyProtocolStatus)
|
2012-03-08 16:55:13 -06:00
|
|
|
break;
|
2010-05-30 07:17:32 -05:00
|
|
|
|
|
|
|
|
BNotification notification(B_PROGRESS_NOTIFICATION);
|
2021-06-22 01:06:00 -05:00
|
|
|
notification.SetGroup(BString(APP_NAME));
|
2010-05-30 07:17:32 -05:00
|
|
|
notification.SetTitle(title);
|
2021-07-18 15:39:30 -05:00
|
|
|
notification.SetIcon(looper->Protocol()->Icon());
|
2010-05-30 07:17:32 -05:00
|
|
|
notification.SetContent(message);
|
|
|
|
|
notification.SetProgress(progress);
|
2010-07-03 02:55:23 -05:00
|
|
|
notification.Send();
|
2010-05-30 07:17:32 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-07-18 15:39:30 -05:00
|
|
|
case IM_NOTIFICATION: {
|
|
|
|
|
_ProtocolNotification(_LooperFromMessage(msg),
|
|
|
|
|
msg->FindString("title"), msg->FindString("message"),
|
|
|
|
|
(notification_type)msg->GetInt32("type",
|
|
|
|
|
B_INFORMATION_NOTIFICATION));
|
2010-05-30 13:56:24 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2021-07-05 23:53:46 -05:00
|
|
|
case IM_PROTOCOL_RELOAD_COMMANDS:
|
|
|
|
|
{
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
if (looper == NULL) break;
|
|
|
|
|
looper->LoadCommands();
|
|
|
|
|
break;
|
|
|
|
|
}
|
2021-06-12 16:13:52 -05:00
|
|
|
case IM_PROTOCOL_READY:
|
|
|
|
|
{
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
2021-07-05 23:53:46 -05:00
|
|
|
if (looper == NULL) break;
|
2021-06-12 16:13:52 -05:00
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
// Ready notification
|
|
|
|
|
if (AppPreferences::Item()->NotifyProtocolStatus == true)
|
2021-07-19 09:54:27 -05:00
|
|
|
_ProtocolNotification(looper, BString(B_TRANSLATE("Connected")),
|
|
|
|
|
BString(B_TRANSLATE("%user% has connected!")));
|
2021-06-12 21:42:10 -05:00
|
|
|
|
|
|
|
|
// Join cached rooms
|
|
|
|
|
BEntry entry;
|
|
|
|
|
char fileName[B_FILE_NAME_LENGTH] = {'\0'};
|
2021-07-18 15:39:30 -05:00
|
|
|
BDirectory dir(RoomsCachePath(looper->Protocol()->GetName()));
|
2021-06-12 21:42:10 -05:00
|
|
|
|
|
|
|
|
while (dir.GetNextEntry(&entry, true) == B_OK)
|
|
|
|
|
if (entry.GetName(fileName) == B_OK) {
|
2021-06-13 02:34:11 -05:00
|
|
|
int32 flags;
|
|
|
|
|
BFile file(&entry, B_READ_ONLY);
|
|
|
|
|
if (file.InitCheck() != B_OK)
|
|
|
|
|
continue;
|
|
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
if (file.ReadAttr("Chat:flags", B_INT32_TYPE, 0, &flags,
|
2021-06-13 02:34:11 -05:00
|
|
|
sizeof(int32)) < 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!(flags & ROOM_AUTOJOIN) && !(flags & ROOM_AUTOCREATE))
|
|
|
|
|
continue;
|
|
|
|
|
|
2021-06-12 21:42:10 -05:00
|
|
|
BMessage join(IM_MESSAGE);
|
2021-06-13 02:34:11 -05:00
|
|
|
int32 im_what = IM_JOIN_ROOM;
|
|
|
|
|
if (flags & ROOM_AUTOCREATE) {
|
|
|
|
|
im_what = IM_CREATE_CHAT;
|
|
|
|
|
join.AddString("user_id", fileName);
|
|
|
|
|
}
|
|
|
|
|
join.AddInt32("im_what", im_what);
|
2021-06-12 21:42:10 -05:00
|
|
|
join.AddString("chat_id", fileName);
|
|
|
|
|
looper->PostMessage(&join);
|
|
|
|
|
}
|
2021-06-12 16:13:52 -05:00
|
|
|
break;
|
|
|
|
|
}
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
case IM_PROTOCOL_DISABLE:
|
2021-07-18 15:39:30 -05:00
|
|
|
{
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
int64 instance = 0;
|
|
|
|
|
if (msg->FindInt64("instance", &instance) != B_OK) {
|
|
|
|
|
result = B_SKIP_MESSAGE;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
RemoveProtocolLooper(instance);
|
2021-07-18 15:39:30 -05:00
|
|
|
break;
|
|
|
|
|
}
|
2010-05-07 04:47:10 -05:00
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
void
|
|
|
|
|
Server::ImError(BMessage* msg)
|
|
|
|
|
{
|
|
|
|
|
const char* error = NULL;
|
|
|
|
|
const char* detail = msg->FindString("detail");
|
|
|
|
|
ProtocolLooper* looper = _LooperFromMessage(msg);
|
|
|
|
|
|
|
|
|
|
if (msg->FindString("error", &error) != B_OK || looper == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
// Format error message
|
|
|
|
|
BString errMsg(looper->Protocol()->GetName());
|
|
|
|
|
errMsg << " ― " << error;
|
|
|
|
|
if (detail)
|
|
|
|
|
errMsg << "\n\n" << detail;
|
|
|
|
|
|
2021-07-19 09:54:27 -05:00
|
|
|
BAlert* alert = new BAlert(B_TRANSLATE("Error"), errMsg.String(),
|
|
|
|
|
B_TRANSLATE("OK"), NULL, NULL, B_WIDTH_AS_USUAL, B_STOP_ALERT);
|
2021-07-18 15:39:30 -05:00
|
|
|
alert->Go();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-31 13:04:58 -05:00
|
|
|
void
|
2021-06-20 12:44:20 -05:00
|
|
|
Server::AddProtocolLooper(bigtime_t instanceId, ChatProtocol* cayap)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper = new ProtocolLooper(cayap, instanceId);
|
2021-05-31 13:04:58 -05:00
|
|
|
fLoopers.AddItem(instanceId, looper);
|
2021-06-01 21:43:19 -05:00
|
|
|
fAccounts.AddItem(cayap->GetName(), instanceId);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
Server::RemoveProtocolLooper(bigtime_t instanceId)
|
|
|
|
|
{
|
2021-06-11 20:33:28 -05:00
|
|
|
ProtocolLooper* looper = GetProtocolLooper(instanceId);
|
|
|
|
|
if (looper == NULL)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
ChatMap chats = looper->Conversations();
|
|
|
|
|
for (int i = 0; i < chats.CountItems(); i++)
|
|
|
|
|
delete chats.ValueAt(i);
|
|
|
|
|
|
|
|
|
|
UserMap users = looper->Users();
|
|
|
|
|
for (int i = 0; i < users.CountItems(); i++)
|
|
|
|
|
delete users.ValueAt(i);
|
|
|
|
|
|
|
|
|
|
fLoopers.RemoveItemFor(instanceId);
|
|
|
|
|
fAccounts.RemoveItemFor(looper->Protocol()->GetName());
|
|
|
|
|
looper->Lock();
|
|
|
|
|
looper->Quit();
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-01 21:43:19 -05:00
|
|
|
ProtocolLooper*
|
|
|
|
|
Server::GetProtocolLooper(bigtime_t instanceId)
|
|
|
|
|
{
|
|
|
|
|
bool found = false;
|
|
|
|
|
return fLoopers.ValueFor(instanceId, &found);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
AccountInstances
|
|
|
|
|
Server::GetAccounts()
|
|
|
|
|
{
|
|
|
|
|
return fAccounts;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-31 13:04:58 -05:00
|
|
|
void
|
|
|
|
|
Server::SendProtocolMessage(BMessage* msg)
|
|
|
|
|
{
|
|
|
|
|
// Skip null messages
|
|
|
|
|
if (!msg)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
// Check if message contains the instance field
|
|
|
|
|
bigtime_t id;
|
|
|
|
|
if (msg->FindInt64("instance", &id) == B_OK) {
|
|
|
|
|
bool found = false;
|
|
|
|
|
ProtocolLooper* looper
|
|
|
|
|
= fLoopers.ValueFor(id, &found);
|
|
|
|
|
|
|
|
|
|
if (found)
|
|
|
|
|
looper->PostMessage(msg);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
Server::SendAllProtocolMessage(BMessage* msg)
|
|
|
|
|
{
|
|
|
|
|
// Skip null messages
|
|
|
|
|
if (!msg)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
// Send message to all protocols
|
|
|
|
|
for (uint32 i = 0; i < fLoopers.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueAt(i);
|
|
|
|
|
looper->PostMessage(msg);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RosterMap
|
|
|
|
|
Server::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
|
|
|
RosterMap contacts;
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
contacts.AddList(fruitLoop->Contacts());
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return contacts;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-23 14:39:07 -05:00
|
|
|
Contact*
|
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
|
|
|
Server::ContactById(BString id, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
Contact* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->ContactById(id);
|
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
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
|
|
|
Server::AddContact(Contact* contact, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->AddContact(contact);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
UserMap
|
|
|
|
|
Server::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
|
|
|
UserMap users;
|
|
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
users.AddList(fruitLoop->Users());
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return users;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
User*
|
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
|
|
|
Server::UserById(BString id, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
User* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->UserById(id);
|
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
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
|
|
|
Server::AddUser(User* user, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->AddUser(user);
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ChatMap
|
|
|
|
|
Server::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
|
|
|
ChatMap chats;
|
2021-05-31 13:04:58 -05:00
|
|
|
|
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
|
|
|
for (int i = 0; i < fAccounts.CountItems(); i++) {
|
|
|
|
|
ProtocolLooper* fruitLoop = fLoopers.ValueFor(fAccounts.ValueAt(i));
|
|
|
|
|
if (fruitLoop == NULL) continue;
|
2021-06-15 14:40:28 -05:00
|
|
|
chats.AddList(fruitLoop->Conversations());
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return chats;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
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*
|
|
|
|
|
Server::ConversationById(BString id, int64 instance)
|
2021-05-31 13:04:58 -05:00
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
Conversation* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->ConversationById(id);
|
|
|
|
|
return result;
|
2021-05-31 13:04:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-04 16:32:18 -05:00
|
|
|
void
|
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
|
|
|
Server::AddConversation(Conversation* chat, int64 instance)
|
2021-06-04 16:32:18 -05:00
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
looper->AddConversation(chat);
|
2021-06-04 16:32:18 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-15 00:19:52 -05:00
|
|
|
ChatCommand*
|
2021-06-15 00:59:00 -05:00
|
|
|
Server::CommandById(BString id, int64 instance)
|
2021-06-15 00:19:52 -05:00
|
|
|
{
|
2021-06-15 00:59:00 -05:00
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(instance);
|
|
|
|
|
ChatCommand* result = NULL;
|
|
|
|
|
if (looper != NULL)
|
|
|
|
|
result = looper->CommandById(id);
|
|
|
|
|
if (result == NULL)
|
|
|
|
|
result = fCommands.ValueFor(id);
|
|
|
|
|
return result;
|
2021-06-15 00:19:52 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-06-15 21:05:21 -05:00
|
|
|
BObjectList<BMessage>
|
2021-06-16 04:33:06 -05:00
|
|
|
Server::ChatPopUpItems()
|
2021-06-15 21:05:21 -05:00
|
|
|
{
|
|
|
|
|
return fChatItems;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BObjectList<BMessage>
|
|
|
|
|
Server::UserPopUpItems()
|
|
|
|
|
{
|
|
|
|
|
return fUserItems;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
ProtocolLooper*
|
|
|
|
|
Server::_LooperFromMessage(BMessage* message)
|
2010-05-07 04:47:10 -05:00
|
|
|
{
|
2010-05-16 16:02:50 -05:00
|
|
|
if (!message)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
bigtime_t identifier;
|
|
|
|
|
|
|
|
|
|
if (message->FindInt64("instance", &identifier) == B_OK) {
|
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
|
|
ProtocolLooper* looper = fLoopers.ValueFor(identifier, &found);
|
|
|
|
|
if (found)
|
|
|
|
|
return looper;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-23 14:39:07 -05:00
|
|
|
Contact*
|
2021-05-31 11:56:45 -05:00
|
|
|
Server::_EnsureContact(BMessage* message)
|
2010-05-16 16:02:50 -05:00
|
|
|
{
|
2021-05-24 01:47:21 -05:00
|
|
|
BString id = message->FindString("user_id");
|
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
|
|
|
ProtocolLooper* looper = _LooperFromMessage(message);
|
|
|
|
|
if (looper == NULL) return NULL;
|
2010-05-16 16:02:50 -05:00
|
|
|
|
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* contact = looper->ContactById(id);
|
|
|
|
|
|
|
|
|
|
if (contact == NULL && id.IsEmpty() == false && looper != NULL) {
|
2021-05-31 11:56:45 -05:00
|
|
|
contact = new Contact(id, Looper());
|
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->SetProtocolLooper(looper);
|
|
|
|
|
looper->AddContact(contact);
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
return contact;
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
User*
|
|
|
|
|
Server::_EnsureUser(BMessage* message)
|
2021-05-24 01:47:21 -05:00
|
|
|
{
|
|
|
|
|
BString id = message->FindString("user_id");
|
2021-06-02 16:53:03 -05:00
|
|
|
return _EnsureUser(id, _LooperFromMessage(message));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
User*
|
|
|
|
|
Server::_EnsureUser(BString id, ProtocolLooper* protoLooper)
|
|
|
|
|
{
|
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* user = protoLooper->UserById(id);
|
2021-05-24 01:47:21 -05:00
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
if (user == NULL && id.IsEmpty() == false) {
|
|
|
|
|
user = new User(id, Looper());
|
2021-06-02 16:53:03 -05:00
|
|
|
user->SetProtocolLooper(protoLooper);
|
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
|
|
|
protoLooper->AddUser(user);
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
2021-05-31 11:56:45 -05:00
|
|
|
return user;
|
2021-05-24 01:47:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conversation*
|
|
|
|
|
Server::_EnsureConversation(BMessage* message)
|
|
|
|
|
{
|
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
|
|
|
ProtocolLooper* looper;
|
|
|
|
|
if (!message || (looper = _LooperFromMessage(message)) == NULL)
|
2021-05-24 01:47:21 -05:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
BString chat_id = message->FindString("chat_id");
|
|
|
|
|
Conversation* item = NULL;
|
|
|
|
|
|
|
|
|
|
if (chat_id.IsEmpty() == false) {
|
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
|
|
|
item = looper->ConversationById(chat_id);
|
2010-05-07 04:47:10 -05:00
|
|
|
|
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
|
|
|
if (item == NULL) {
|
2021-05-24 01:47:21 -05:00
|
|
|
item = new Conversation(chat_id, Looper());
|
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
|
|
|
item->SetProtocolLooper(looper);
|
2021-07-06 14:46:28 -05:00
|
|
|
item->AddUser(looper->GetOwnContact());
|
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
|
|
|
looper->AddConversation(item);
|
2021-06-13 01:16:30 -05:00
|
|
|
|
|
|
|
|
BMessage meta(IM_MESSAGE);
|
|
|
|
|
meta.AddInt32("im_what", IM_GET_ROOM_METADATA);
|
|
|
|
|
meta.AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
|
|
BMessage users(IM_MESSAGE);
|
|
|
|
|
users.AddInt32("im_what", IM_GET_ROOM_PARTICIPANTS);
|
|
|
|
|
users.AddString("chat_id", chat_id);
|
|
|
|
|
|
|
|
|
|
looper->MessageReceived(&meta);
|
|
|
|
|
looper->MessageReceived(&users);
|
2010-05-07 04:47:10 -05:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return item;
|
|
|
|
|
}
|
2021-05-23 14:39:07 -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*
|
|
|
|
|
Server::_GetRole(BMessage* msg)
|
|
|
|
|
{
|
|
|
|
|
if (!msg)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
BString title;
|
2021-06-06 01:49:11 -05:00
|
|
|
int32 perms;
|
|
|
|
|
int32 priority;
|
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
|
|
|
|
|
|
|
|
if (msg->FindString("role_title", &title) != B_OK
|
2021-06-06 01:49:11 -05:00
|
|
|
|| msg->FindInt32("role_perms", &perms) != B_OK
|
|
|
|
|
|| msg->FindInt32("role_priority", &priority) != B_OK)
|
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
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
return new Role(title, perms, priority);
|
|
|
|
|
}
|
2021-07-18 15:39:30 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
Server::_ProtocolNotification(ProtocolLooper* looper, BString title,
|
|
|
|
|
BString desc, notification_type type)
|
|
|
|
|
{
|
|
|
|
|
if (looper == NULL || title.IsEmpty() == true) return;
|
|
|
|
|
title.ReplaceAll("%user%", looper->Protocol()->GetName());
|
|
|
|
|
desc.ReplaceAll("%user%", looper->Protocol()->GetName());
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
_SendNotification(title, desc, looper->Protocol()->Icon(), type);
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-18 15:39:30 -05:00
|
|
|
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
void
|
|
|
|
|
Server::_SendNotification(BString title, BString content, BBitmap* icon,
|
|
|
|
|
notification_type type)
|
|
|
|
|
{
|
2021-07-18 15:39:30 -05:00
|
|
|
BNotification notification(type);
|
|
|
|
|
notification.SetGroup(BString(APP_NAME));
|
|
|
|
|
notification.SetTitle(title);
|
Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).
Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.
This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().
In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
|
|
|
if (content.IsEmpty() == false)
|
|
|
|
|
notification.SetContent(content);
|
|
|
|
|
if (icon != NULL)
|
|
|
|
|
notification.SetIcon(icon);
|
2021-07-18 15:39:30 -05:00
|
|
|
notification.Send();
|
|
|
|
|
}
|
