[Bug 28367] Add StreamTube interface support

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jun 9 21:06:42 CEST 2010


https://bugs.freedesktop.org/show_bug.cgi?id=28367

--- Comment #6 from Dario Freddi <drf54321 at gmail.com> 2010-06-09 12:06:42 PDT ---
(In reply to comment #5) 
> Indeed, the fix is spot on, ++ ;)

:)

> 
> What I mean is, similarly to the allKnownContactsChanged() stuff we previously
> worked into TpQt4, currently if some other application (the Handler) using the
> (D-Bus level) Channel does Offer, and you're an application using TpQt4 (most
> likely an Observer) and having an OutgoingStreamTubeChannel for said channel,
> you won't get the Parameters updated.

Ok - now I see the point.

> 
> What SHOULD happen in this case is, the Observing TpQt4 delays emitting
> tubeStateChanged to Offered/Open UNTIL it has re-introspected the Parameters
> property (since it has been changed on the CM object by some other application,
> not us doing offer*(), similarly to how the known contacts could change because
> some other application did a roster modify operation). Still, I'm going to opt
> for the FIXME comment describing this and not bothering with it now, as the use
> case seems rather slim - I think the only applications caring about Parameters
> should be the ones having the actual socket and needing to match with the
> bootstrap stuff (handshakes / HELLO-style message / alike) the parameters
> represent, and these applications should be the Handler / the one doing offer()
> anyway.

I agree - it seems overkill to me at this stage, and not really useful. I'll
add a FIXME later.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list