Creating an IM system - best scenario?

Question

Hi,
We are planning on adding an Instant Messaging feature to an application used by two kind of users : customers and agents.
The goal is to allow text/audio/video chat (possibly with the three options simultaneously but most likely with either text or audio+video) with the following use cases:
Agent (1 or 2) <-> Customer (one-one or two-one)
Agent <-> Agent (multiple users)
Multiple opened chat session for a given user (mutiple windows similar to gmail)
We also need to display a list of users (both online and offline + capabilities (mic,webcam)) -> should we leverage some kind of main room for this as well?
So far we have identified three possible scenarios to achieve this:
One Room per chat/conversion : the user would need to create a new room from a template and send the url to other recipients (through a global message bus, maybe a global/general room). This also implies having multiple session opened as a user can have multiple one-one conversations
Create only  one room and use groupNames to manage the privacy of a conversation  but that seems to create one collectionNode per groupName and I’m not  sure how that will scale on the long run.
The  last option would be to send everything to a single collectionNode (like in  the simpleChatModel) and simply rely on the  recipiendIDs to manage the  privacy but that seems a bit overcomplicated to manage a conversation  with multiple users as we would first need to share the list of members for a given chat.
Would you guys have ideas or recommendations around this or maybe an Instant Messaging exemple?
Thanks,
Nicolas

Answer 1

Hi Nicolas,
I think there are 2 aspects to what you're planning :
1) A lobby system with buddy-style presence for "rendez-vous" to the private
conversations
2) Private rooms that are used for the actual conversations
For 1), you'll want to use UserManager.anonymousPresence - this means that
not every person logged into the lobby will be able to see each other;
rather, only people who have broadcast their presence to the room on purpose
(so that everyone can see them) or with pre-defined relationships (such as
from a buddy list) will be seen. Anonymous presence greatly increases the
scale of our rooms into the thousands of connections. Secondly, you can use
UserManager.myBuddyList for each user who is connecting - assign a list of
userIDs that the current user should notify when he arrives.
For 2), when a private conversation needs to happen, have the initiator
request a new room from your server. Your server can validate the request,
and use the server integration libraries to create a new LCCS room, and
return the URL to the initiator. From there, the initiator can privately
message the URL to the person they're inviting (within some node in the
lobby room through which messages with recipientIDs can be used).
I think it's fine to have multiple sessions open at once from the client
(for example, the client would likely stay connected to the lobby the whole
time so that presence is reflected). So I definitely recommend the first
option you presented, with the addition of a general lobby room for generic
presence and rendez-vous. In this way you get the benefits of a centralized
presence system with the scale of private chats happening within their own
rooms.
  This is definitely an area we on the product team are looking to document
further - we've rather quietly added the UserManager functionality above,
and have been planning out sample lobby systems to share. We're heads-down
in a release that's coming out very soon , but once that's done, we'll
start to get some more samples together on this topic.
  hope that helps - let us know if we can answer any further questions.
  thanks
  nigel