[Bug 24661] Define per-connection "sidecar" objects
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Nov 12 17:09:14 CET 2009
http://bugs.freedesktop.org/show_bug.cgi?id=24661
--- Comment #7 from Will Thompson <will.thompson at collabora.co.uk> 2009-11-12 08:09:13 PST ---
So I've been agonizing about this some more. Having the only change
notification for Sidecars being the connection moving to Connected seems like a
great idea, but in fact may not be. On XMPP, we could imagine sidecars being
dependent on server components returned in the disco#items query to the server,
so you have to disco a whole bunch of jids — which might be on different
machines to your server, and may have fallen down a well so you need to wait
for them to time out — before you move to Connected. (Gabble currently moves
to Connected before doing any of this, presumably for this reason.)
So, I thought to myself, we need a SidecarAdded signal. But actually that's not
good enough: clients need to be able to know whether a sidecar will ever show
up, or if they're going to be sitting around waiting for SidecarAdded forever.
Let's add a method:
RequestSidecar ( s: Interface)
→ ( o: Sidecar_Path
, a{sv}: Properties
)
Then a client which wants a particular sidecar can just call that method, and
when it returns deal with the error or use the sidecar. Given this, there's
relatively little need for the Sidecars property at all: if you want one, ask
for it.
Explicitly requesting sidecars also means that if a sidecar is expensive in
terms of network traffic, it doesn't have to be initialized unless someone
actually wants it.
Thoughts?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the telepathy-bugs
mailing list