As I said to Matt, sorry for the delay in my reply.
Cool. As you may know, we have an XMPP server, Jive
Messenger, in development (pure Java). Anonymous
authentication isn’'t implemented mainly for security
reasons (we need time to figure out how to make it
manageable). For XMPP development, it’'s an ideal,
XMPP server that runs easily on any platform with
Java 1.3 or later. Smack is being developed against
Jive Messenger so you can expect features to appear
in parallel between the two… I’'ll add anonymous
authentication to our issue tracker.
Pure Java always rocks! Thanks for adding the anon authentication to the list!
XMPP tries to route messages to a jid with a best
effort algorithm. A message sent to
firstname.lastname@example.org/resource goes to that particular
resource if it is online. However if a message is
sent to a resource that is not available, the message
is routed as if the message was sent to
email@example.com. In other words, the message is
transmitted to the ‘‘preferred’’ resource, determined
by highest seen by the server in a
presence packet from a particular resource.
So the most typical scenario for packets to get
redirected to the wrong client would be if your agent
were chatting with a user firstname.lastname@example.org/clientA and
email@example.com/clientB and clientA logs off and the
agent sends another message not realizing clientA has
logged off. Then the server will see clientA
unavailable and reroute it to clientB.
I see, sounds like a simple enough process to me. Have you any other algorithms in development worth mentioning?
I was thinking about that. One possibility would be
to actually have everyone log in to one account with
different resources as discussed earlier. However,
instead of conducting one-on-one chats, each
customer’'s client actually joins a unique groupchat
room and sends an invitation to the agent’'s client to
join that chatroom. The agent’'s client will join the
chatroom and then messages sent to the chatroom will
show up in both agent and customer’'s clients. When
the customer wants, they can log off by leaving the
chatroom and then logging out. It’'s importantant that
they leave the chatroom first. That makes sure that
any messages that the agent sends to the chatroom
stay in the chatroom rather than get transmitted to
the customer. Since no groupchat messages go to the
customer when they are not in a chatroom, this should
prevent any stray messages from ever being sent to
Chatrooms are also nice because you can have multiple
participants join the chat. This would allow an agent
to invite another agent to join the chat which could
be useful. In addition, you could invite a simple
chatbot client to the room that could automatically
log everything in the chatroom to a database or
logfile or to listen in on the conversations and
automatically provide information. For example, if
you go into a conference.jabber.org chatroom and type
‘’?? query’’ without the quotes and with query being
what you want to know about like ‘’?? XMPP’’ you’'ll see
a chatbot answer). Or try ‘’!time’’ to get the time
from another chatbot. This may be a great tool for
agents to easily send common information from a faq
or something to the user in a chat session.
The group chat was one of the idea’‘s I too was thinking about. The way you describe it, it does seem like a very viable solution to the routing problem, but one that I may have to test before making a final decision. Thanks for the extra info regarding queries in the chatroom - I didn’'t even realise these existed.
Hope that helps.
Yes, thank you ever so much, I’'ve got lots more ideas flying around in my head now due to this very informative discussion. Thank you for taking the time to make all this information clear to me and any others who read this thread.