Hello,
What are the actual disadvantages of Client::send().
Can you please explian the difference in implementation of Client:send and
MessageSession:send
that makes the difference?
Thanks,
Anatoly
2006/12/6, Jakob Schroeter <js@xxxxxxxxxx>:
On Wednesday December 6 2006 05:03, Oleg Titov wrote:
> Hello list,
>
> I am getting brain freeze with MessageSession approach. Specially
> with this part of the code:
> virtual void MyClass::handleMessageSession( MessageSession *session )
> {
> // this leaks heavily if there was an earlier session
> m_session = session;
> m_session->registerMessageHandler( this );
>
> I do understand that if I get second session going this code will
> loose all references to old session and this will generate memory
> leaks, and logic flow break. What I can not understand is how to
> handle several sessions. I feel that each session is already linked to
> senders JID, so I do not understand why I need to save sessions (I do
> understand that I need to have references to sessions to gracefully
> free registered corresponding handlers) as I expect that they wil
> autodestruct or something. From other part, if I have a list of
> current sessions I do not quite understand how to identify which
> session to use in handleMessage to send a response messages (I almost
> refer to examples supplied with source distribution).
The MessageSession::target() function tells you the JID the MessageSession
communicates with. Also, you need the MessageSession to actually send()
something to the contact. Using Client::send() is not recommended (it does
work, though).
Usually I use one MessageSession per chat window (or an equivalent
abstraction). That way you also have some kind of 'external'
identification
of the chat partner.
Using target(), a simple list<MessageSession*> should do if you don't have
any
such additional abstraction of a conversation.
That said, it would probably be even better if the handleMessage()
function
would take the current MessageSession as a parameter.
Any feedback appreciated.
cheers,
Jakob
--
gloox-dev mailing list
to unsubscribe:
send a message with subject 'unsubscribe gloox-dev' to
minimalist@xxxxxxxxxx