[Bug 28367] Add StreamTube interface support

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Olli Salli <ollisal at gmail.com> 2010-06-09 09:50:15 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> 
> So true :) Fixed in 2c9b755f850d41f781e8e3f67299f228ce23dcd4

Indeed, the fix is spot on, ++ ;)

> 
> > 
> > Another thing where we actually might need real reintrospection for would be if
> > somebody else does offer() and we are just monitoring the tube. This would
> > require us to react to the TubeStateChanged to Offered and delay emitting it
> > until we've re-introspected the param. However, the current implementation
> > doesn't cater for it either. But, I don't think this use-case of monitoring a
> > tube getting offered AND needing to use the parameters for something actually
> > even exists, so I'm fine with fixing the needless reintrospection and
> > consequent indeterministic parameters update in the common case as outlined
> > above. Maybe put a FIXME in there explaining that parameters doesn't correctly
> > update if you're not the one offering the tube though.
> 
> I actually did not touch anything here as I did not get the whole drill
> 

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.

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.

-- 
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.