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.