[Telepathy] Get existing connection in clients

[Dafydd Harries]

Ar 08/02/2007 am 12:04, ysgrifennodd Xavier Claessens:
> On ven, 2007-01-19 at 09:55 +0100, Xavier Claessens wrote:
> > On jeu, 2007-01-18 at 22:55 +0100, Xavier Claessens wrote:
> > > On jeu, 2007-01-18 at 21:39 +0000, Dafydd Harries wrote:
> > > > Ar 18/01/2007 am 22:30, ysgrifennodd Xavier Claessens:
> > > > > 1) RequestConnection returns the existing object if it's already
> > > > > connected. Currently if I try to connect an account that is already
> > > > > connected I get this error:
> > > > > 
> > > > > * (gossip:6771): WARNING **: Connect() failed: Error acquiring bus name
> > > > > org.freedesktop.Telepathy.Connection.idle.irc.xclaesse_irc_freenode_net,
> > > > > The connection manager already has this connection active.
> > > > 
> > > > Why not just call RequestConnection and catch the error to determine whether
> > > > the connection exists? If you don't need the resulting connection object, you
> > > > can just call Disconnect() on it.
> > > 
> > > It can be a solution if all CM returns the same error. So there is three
> > > solutions:
> > > 
> > > 3) Add in the spec a possible error on RequestConnection telling it's
> > > already connected.
> > > 
> > 
> > Hum after some thinking, return an error isn't that useful. It just
> > tells the client that a connection exists but it doesn't says the
> > object's path on the bus.
> > 
> > Xavier.
> 
> 
> Ok so finally what can be done here ?!?
> 
> I need this problem fixed because it currently prevent gossip to connect
> multiple IRC server. The problem is gossip reuse an existing connection
> if the "account" parameter is the same, which is wrong for irc account!

I'm not convinced that we need spec changes to address this problem. It seems
to me that this is a bug in Gossip: it assumes that the account parameter
uniquely describes a connection when this is not the case.

Perhaps what really needs fixing is the fact that the connection manager
cannot easily identify which parameters make a connection unique; one approach
to changing this would be to add a "unique" flag to the .manager file.

-- 
Dafydd