[Telepathy] TelepathyQt4: State of the Connection

[Andre Moreira Magalhaes]

Olli Salli wrote:
>>> 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.
>
>   
Indeed.

Today it already waits for becomeReady(requestedFeatures), but 
requestedFeatures being passed as args for requestConnect. As the ready 
stuff is not working properly today this does not work as expected, but 
fixing the ready stuff, this should work automatically.
> 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.
>
>
>   

Agree also

BR
Andre