Hi,
-Original Message-
From: eop...@gmail.com [mailto:eop...@gmail.com] On Behalf Of ext
Edward Page
Sent: Saturday, March 13, 2010 6:51 PM
To: Zabaluev Mikhail (Nokia-D/Helsinki)
Cc: sjo...@luon.net; telepathy@lists.freedesktop.org
Subject: Re: [Telepathy] Best way to handle
On Mon, Mar 15, 2010 at 9:07 AM, mikhail.zabal...@nokia.com wrote:
Yes, it was a problem with our implementation: blocking on disconnection
meant that a RequestConnection call to reestablish the connection timed out.
Even if blocking is resolved, making an object linger in disconnecting
On Wed, Mar 10, 2010 at 7:14 AM, mikhail.zabal...@nokia.com wrote:
To make Mission Control happy, a connection manager should not block its
internal event loop which processes D-Bus method calls, at least at the time
when RequestConnection is called. If the RequestConnection D-Bus call times
: [Telepathy] Best way to handle the client leaking
connections?
This seems to be an issue in the client. Which client are you using?
Definately
this shouldn't happen if mission control is used.
This was all on Maemo 5 using the built in client (RTComm/MC ?). I
found a related bug report
On Sat, Feb 27, 2010 at 12:54:59PM -0600, Edward Page wrote:
With The One Ring (GV Connection Manager) I've had a long standing bug
about the inability to reconnect. The issue is the user's Connection
was never being cleaned up so another connection could never be made.
I traced various
On Tue, Mar 9, 2010 at 1:12 PM, Sjoerd Simons sjo...@luon.net wrote:
I noticed I still had an issue. I looked closer at my logs (for
example see log mentioned in the bug or its analysis in the above
referenced forum post) and realized what appears to be calls to the
Connection Manager's
With The One Ring (GV Connection Manager) I've had a long standing bug
about the inability to reconnect. The issue is the user's Connection
was never being cleaned up so another connection could never be made.
I traced various aspects of it to ways I deviate from the spec and
leaking of some
