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.
|
2010-05-16 16:02:50 -05:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
|
*/
|
|
|
|
|
#ifndef _PROTOCOL_LOOPER_H
|
|
|
|
|
#define _PROTOCOL_LOOPER_H
|
|
|
|
|
|
|
|
|
|
#include <Looper.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 <String.h>
|
|
|
|
|
|
|
|
|
|
#include <libsupport/KeyMap.h>
|
2010-05-16 16:02:50 -05:00
|
|
|
|
|
|
|
|
#include "CayaProtocol.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
|
|
|
class Contact;
|
|
|
|
|
class Conversation;
|
|
|
|
|
class User;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
typedef KeyMap<BString, Conversation*> ChatMap;
|
|
|
|
|
typedef KeyMap<BString, Contact*> RosterMap;
|
|
|
|
|
typedef KeyMap<BString, User*> UserMap;
|
|
|
|
|
|
|
|
|
|
|
2010-05-16 16:02:50 -05:00
|
|
|
class ProtocolLooper : public BLooper {
|
|
|
|
|
public:
|
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(CayaProtocol* protocol, int64 instance);
|
|
|
|
|
|
|
|
|
|
void MessageReceived(BMessage* msg);
|
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
|
|
|
CayaProtocol* Protocol();
|
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
|
|
|
ChatMap Conversations() const;
|
|
|
|
|
Conversation* ConversationById(BString id);
|
|
|
|
|
void AddConversation(Conversation* chat);
|
|
|
|
|
void RemoveConversation(Conversation* chat);
|
|
|
|
|
|
|
|
|
|
RosterMap Contacts() const;
|
|
|
|
|
Contact* ContactById(BString id);
|
|
|
|
|
void AddContact(Contact* contact);
|
|
|
|
|
|
|
|
|
|
UserMap Users() const;
|
|
|
|
|
User* UserById(BString id);
|
|
|
|
|
void AddUser(User* user);
|
|
|
|
|
|
|
|
|
|
BString GetOwnId();
|
|
|
|
|
void SetOwnId(BString user_id);
|
|
|
|
|
|
|
|
|
|
int64 GetInstance();
|
2010-05-16 16:02:50 -05:00
|
|
|
|
|
|
|
|
private:
|
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
|
|
|
CayaProtocol* fProtocol;
|
|
|
|
|
int64 fInstance;
|
|
|
|
|
|
|
|
|
|
BString fMySelf;
|
|
|
|
|
|
|
|
|
|
ChatMap fChatMap;
|
|
|
|
|
RosterMap fRosterMap;
|
|
|
|
|
UserMap fUserMap;
|
2010-05-16 16:02:50 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif // _PROTOCOL_LOOPER_H
|
