Handling incoming chat sessions

Smack Smack Dev
1

I was checking out matt’‘s changeset 2779. He introduced a very nice way of assigning incoming messages to chat sessions when the messages don’'t carry a thread ID. Unfortunately, there is still some functionality missing that would require duplicating his efforts on the application.

In a private e-mail I wrote to him:

My problem is that if I use this feature, I get some duplicated messages for previously existing Chat sessions: one from my Message-packet listener and one from Chat’‘s listener. My listener is necessary, otherwise I don’‘t get notifications for incoming chat messages from users I haven’'t contacted before (i.e., for which there are no chat-sessions established). The unfortunate part is that in order to be able to tell whether an incoming message corresponds to a new session or not, it seems that I need to duplicate the code you added to Chat. Am I missing something obvious?

And he said no, that this problem is known.

I can fix this in a few minutes, but I’'d prefer reaching some consense here first. My suggestion is either adding a static chat factory or a new chat-listener to the XMPPConnection. With the former the application has some control on the creation of Chat sessions, being able to veto creation of new sessions, reusing them, or subclassing them; with the latter, the application is told that a new Chat session has been created (and the Chat instance will probably be passed to the listener), but it has no direct control on the process. The latter is simpler and hence probably preferred, but adding one or the other requires the same effort to me, so I leave it open to you.

Also, I’'d be glad to hear other suggestions.

Unfortunately I can’‘t wait long to implement this, so I’‘ll probably have something by tomorrow morning, independently on whether consensus can be reached here. I’'ll post the patch afterwards.

2

This is what I came up with. It fixes a couple issues in the aforementioned changes my matt, plus adds what I needed.

Sorry about the Java 5-specific code, but it’‘s easy to revert back to what Smack uses. Also, this will not apply cleanly to Smack’'s SVN trunk or version 2.0.0, as my version diverges significantly from it, but most of it should apply fine and the rest should be easy to apply by hand.

I ran tests against GAIM (doesn’‘t send thread ID) and jabber.com’'s client (sends thread ID), and it passed successfully my tests.

As before, this doesn’‘t attempt to handle thread ID bearing messages. I just expanded matt’'s solution to handle new incoming thread-less chat sessions.

Note that the Chat constructors are package protected now. All Chat instances should be created through XMPPConnection.createChat to guarantee that they become registered in the connection’'s chats map. The code was originally in the constructor, but that violates the principle that dictates that no reference to an instance should be leaked before the constructor has finished its execution.
newchat.diff (14856 Bytes)

3

I think that where it reads in XMPPPConnection:

}, new PacketTypeFilter(Message.class));

it should instead read:

}, new MessageTypeFilter(Message.Type.CHAT));

Otherwise it will create Chat sessions for thread-less groupchat messages, and others.