[Telepathy] TelepathyQt4: State of the Connection
Olli Salli
ollisal at gmail.com
Sat Feb 7 05:04:41 PST 2009
>>
>> Maybe I misunderstood some points here but let me say what I understood,
>> feel free to correct me if I am wrong:
>> - In your proposal, connection "ready" by calling becomeReady will work in 2
>> different situations, when you are offline and when you are online. So if
>> the connection is still offline (just created, no requestConnect called),
>> and the user calls becomeReady(...) it will finish all operations, including
>> for no features (0) at some point. If after that the user calls
>> requestConnect it will have to call becomeReady(...) again and wait for it
>> to signal finish.
>> If this is true, as I understood, I would like to propose another solution.
>
> No, this is not the intended use. As I said, statusChanged for the
> online should only be emitted after all features *anyone* has
> previously asked for using becomeReady have been downloaded.
> Therefore, it suffices to first connect to statusChanged, then call
> becomeReady with the desired features. If the connection wasn't online
> at that point, when user code calls requestConnect, a statusChanged
> will be emitted for the Connecting state at which point the user knows
> about nothing will work in the Connection (exceptions should be
> documented on the individual accessors). Then after some time
> statusChanged will be emitted - but only after the features asked for
> previously (in the just-created, offline, connecting and
> connecting-but-before-everything-downloaded states) have been
> downloaded. Therefore there's no need to call becomeReady again.
>
Actually, we might want to do one more thing - in addition to delaying
statusChanged, we could delay finishing the pending operation returned
by requestConnect (decoupling it from the call to the Connect D-Bus
method returning) to the point where all statusChanged would be
emitted. This could be easily accomplished by implementing it as
return becomeReady(requestedFeatures) - requestedFeatures being the
previously mentioned union of all features anyone, ever, has
requested.
Same goes for setSelfPresence (which, as I said before, should work in
the offline state, and make you go online with a specific presence) -
that could return a pending operation which finishes only after
connecting and setting the presence. No need for all of the features
to be ready in that case, though, just the SimplePresence related lot.
--
Br,
Olli Salli
More information about the telepathy
mailing list