2010-05-16 16:02:50 -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 00:59:00 -05:00
|
|
|
* Copyright 2021, Jaidyn Levesque. All rights reserved.
|
2010-05-16 16:02:50 -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 00:59:00 -05:00
|
|
|
* Jaidyn Levesque, jadedctrl@teknik.io
|
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
|
|
|
#include "ProtocolLooper.h"
|
|
|
|
|
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
|
|
|
#include <Bitmap.h>
|
2010-05-16 16:02:50 -05:00
|
|
|
#include <String.h>
|
|
|
|
|
|
|
|
#include "Account.h"
|
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
|
|
|
#include "AppMessages.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 "Conversation.h"
|
2021-06-11 17:24:04 -05:00
|
|
|
#include "ConversationAccountItem.h"
|
2010-05-16 16:02:50 -05:00
|
|
|
|
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
ProtocolLooper::ProtocolLooper(ChatProtocol* protocol, int64 instance)
|
2010-05-19 17:28:26 -05:00
|
|
|
:
|
|
|
|
BLooper(),
|
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
|
|
|
fProtocol(protocol),
|
2021-06-11 17:24:04 -05:00
|
|
|
fInstance(instance),
|
2021-07-07 10:59:56 -05:00
|
|
|
fListItem(NULL),
|
|
|
|
fMySelf(NULL)
|
2010-05-16 16:02:50 -05:00
|
|
|
{
|
|
|
|
Account* account = reinterpret_cast<Account*>(
|
|
|
|
protocol->MessengerInterface());
|
|
|
|
|
2021-07-05 23:53:46 -05:00
|
|
|
LoadCommands();
|
2021-06-20 01:24:34 -05:00
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
BString name(protocol->FriendlySignature());
|
|
|
|
name << " - " << account->Name();
|
|
|
|
|
|
|
|
SetName(name.String());
|
|
|
|
Run();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-11 20:33:28 -05:00
|
|
|
ProtocolLooper::~ProtocolLooper()
|
|
|
|
{
|
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
|
|
|
BMessage* msg = new BMessage(APP_ACCOUNT_DISABLED);
|
|
|
|
BBitmap* icon = fProtocol->Icon();
|
|
|
|
|
|
|
|
icon->Archive(msg);
|
|
|
|
msg->AddString("name", fProtocol->GetName());
|
|
|
|
fProtocol->MessengerInterface()->SendMessage(msg);
|
|
|
|
|
2021-06-11 20:33:28 -05:00
|
|
|
fProtocol->Shutdown();
|
|
|
|
delete fProtocol;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
void
|
|
|
|
ProtocolLooper::MessageReceived(BMessage* msg)
|
|
|
|
{
|
|
|
|
if (Protocol()->Process(msg) != B_OK)
|
|
|
|
BLooper::MessageReceived(msg);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-20 12:44:20 -05:00
|
|
|
ChatProtocol*
|
2010-05-16 16:02:50 -05:00
|
|
|
ProtocolLooper::Protocol()
|
|
|
|
{
|
|
|
|
return fProtocol;
|
|
|
|
}
|
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
|
|
|
|
ProtocolLooper::Conversations() const
|
|
|
|
{
|
|
|
|
return fChatMap;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
Conversation*
|
|
|
|
ProtocolLooper::ConversationById(BString id)
|
|
|
|
{
|
|
|
|
bool found = false;
|
|
|
|
return fChatMap.ValueFor(id, &found);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
ProtocolLooper::AddConversation(Conversation* chat)
|
|
|
|
{
|
|
|
|
fChatMap.AddItem(chat->GetId(), chat);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
ProtocolLooper::RemoveConversation(Conversation* chat)
|
|
|
|
{
|
|
|
|
fChatMap.RemoveItemFor(chat->GetId());
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
RosterMap
|
|
|
|
ProtocolLooper::Contacts() const
|
|
|
|
{
|
|
|
|
return fRosterMap;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
Contact*
|
|
|
|
ProtocolLooper::ContactById(BString id)
|
|
|
|
{
|
|
|
|
bool found = false;
|
|
|
|
return fRosterMap.ValueFor(id, &found);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
ProtocolLooper::AddContact(Contact* contact)
|
|
|
|
{
|
|
|
|
fRosterMap.AddItem(contact->GetId(), contact);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-19 22:37:20 -05:00
|
|
|
void
|
|
|
|
ProtocolLooper::RemoveContact(Contact* contact)
|
|
|
|
{
|
|
|
|
fRosterMap.RemoveItemFor(contact->GetId());
|
|
|
|
fUserMap.AddItem(contact->GetId(), (User*)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
|
|
|
UserMap
|
|
|
|
ProtocolLooper::Users() const
|
|
|
|
{
|
|
|
|
UserMap users = fUserMap;
|
|
|
|
|
|
|
|
for (int i = 0; i < fRosterMap.CountItems(); i++) {
|
|
|
|
User* user = (User*)fRosterMap.ValueAt(i);
|
|
|
|
users.AddItem(user->GetId(), user);
|
|
|
|
}
|
|
|
|
|
|
|
|
return users;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
User*
|
|
|
|
ProtocolLooper::UserById(BString id)
|
|
|
|
{
|
|
|
|
bool found = false;
|
|
|
|
User* user = ContactById(id);
|
|
|
|
if (user == NULL)
|
|
|
|
user = fUserMap.ValueFor(id, &found);
|
|
|
|
|
|
|
|
return user;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
ProtocolLooper::AddUser(User* user)
|
|
|
|
{
|
|
|
|
fUserMap.AddItem(user->GetId(), user);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-15 00:59:00 -05:00
|
|
|
CommandMap
|
|
|
|
ProtocolLooper::Commands() const
|
|
|
|
{
|
|
|
|
return fCommands;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
ChatCommand*
|
|
|
|
ProtocolLooper::CommandById(BString id)
|
|
|
|
{
|
|
|
|
return fCommands.ValueFor(id);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-07-06 14:46:28 -05:00
|
|
|
Contact*
|
|
|
|
ProtocolLooper::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
|
|
|
{
|
|
|
|
return fMySelf;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
void
|
2021-07-06 14:46:28 -05:00
|
|
|
ProtocolLooper::SetOwnContact(Contact* 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
|
|
|
{
|
2021-07-06 14:46:28 -05:00
|
|
|
fMySelf = 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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int64
|
|
|
|
ProtocolLooper::GetInstance()
|
|
|
|
{
|
|
|
|
return fInstance;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-11 17:24:04 -05:00
|
|
|
ConversationAccountItem*
|
|
|
|
ProtocolLooper::GetListItem()
|
|
|
|
{
|
|
|
|
if (fListItem == NULL)
|
|
|
|
fListItem = new ConversationAccountItem(fProtocol->GetName(),
|
|
|
|
fInstance);
|
|
|
|
return fListItem;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-06-20 01:24:34 -05:00
|
|
|
void
|
2021-07-05 23:53:46 -05:00
|
|
|
ProtocolLooper::LoadCommands()
|
2021-06-20 01:24:34 -05:00
|
|
|
{
|
2021-07-05 23:53:46 -05:00
|
|
|
fCommands = CommandMap();
|
2021-06-20 01:24:34 -05:00
|
|
|
BObjectList<BMessage> commands = fProtocol->Commands();
|
|
|
|
for (int i = 0; i < commands.CountItems(); i++) {
|
|
|
|
ChatCommand* cmd = new ChatCommand(commands.ItemAt(i));
|
|
|
|
fCommands.AddItem(cmd->GetName(), cmd);
|
|
|
|
}
|
|
|
|
}
|