[Telepathy] Get existing connection in clients

[Dafydd Harries]

Ar 24/03/2007 am 18:15, ysgrifennodd Dafydd Harries:
> Ar 08/02/2007 am 12:04, ysgrifennodd Xavier Claessens:
> > 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.

Thinking about this again, I don't think the connection manager can compare
arbitrary sets of parameters on behalf of clients. One client may consider a
connection different depending on the SSL setting, whereas another may not
care about SSL.

A different approach would be to be able to recover the connection parameters
from the Connection object, with an allowance for not exposing passwords. This
would imply having protocol-specific knowledge, but we've already established
that it's impossible to construct a good UI for connection parameters that will work for arbitrary protocols.

To summarize, we have various proposals:

 - Allow RequestConnection to return an existing connection. My problem with
   this is that the connection manager makes an arbitrary decision about
   whether the parameters given to RequestConnection are close enough to a
   connection that's already open, and that it pevents the connection manager
   from exiting once the connection has been launched, which was previously a
   valid way of doing things.

 - My suggestion to add extra metadata to the .manager file to hint at which
   parameters are significant when comparing connections. This is not really
   very useful to clients without some way of inspecting the parameters of
   existing connections.

 - Adding a GetParameters call to Connection, as mentioned above. We might
   want to use a different name, as the ConnectionManager already has a method
   by this name, and there are potential benefits of having method names be
   globablly unique, namely that a wrapper API can always derive the interface
   from the method name.

 - Just require clients to coordinate connections using an out-of-band
   mechanism. (I.e. keep the status quo.)

-- 
Dafydd