[Telepathy] TelepathyQt4: State of the Connection

[Andre Moreira Magalhaes]

Olli Salli wrote:
> On Fri, Feb 6, 2009 at 10:34 PM, Andre Moreira Magalhaes
> <andre.magalhaes at collabora.co.uk> wrote:
>   
>> Hi,
>>
>> Olli Salli wrote:
>>     
>>> I might implement these changes myself, but that would occur during
>>> the latter half of next week at the earliest - so if you happen to
>>> find yourself out of work and/or unhappy with how Connection currently
>>> performs, feel free to try and start experimenting on how implementing
>>> this would turn out.
>>>
>>>
>>>       
>> So I finally had time to take a look at those mails and have some things to
>> comment.
>>
>> First the proposal is really good I just have some points I would like to
>> clarify.
>>
>> 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.
>
> If, however, somebody calls becomeReady when the Connection is either
> Connecting or in the transient state where the D-Bus object is
> actually already connected, but the C++ object is still introspecting
> and therefore delaying emitting statusChanged, becomeReady shouldn't
> finish just because those features happened to be ready in the offline
> state. It should only return when the connection is both connected AND
> the asked-for features are present (note: statusChanged can be emitted
> even later on, if somebody else has asked for even more features than
> the becomeReady call in question).
>
> In short, the becomeReady semantics should be "At the time the
> returned pendingOperation finishes, the features asked for are ready
> for the then-current connection state. Additionally, by the time any
> further status changes are signaled, those features will also be ready
> for that state".
>
>   
>> In all other classes isReady/becomeReady should be called just once, and
>> when they signal finish, it mean they finished for the whole class, not for
>> a state of the class. I would like this to be true for connection also, so
>> the proposal is as follow.
>>     
>
> In Connection's case the "whole class" can never be ready at the same
> time though - only the parts of it relevant to the current state. For
> both states, becomeReady should return as soon as everything asked for
> is ready, but of course, it in absolutely no way can make the
> guarantee that "these features will be always usable, despite any
> Connection state changes". Just for the current state - there is,
> necessarily, a point of time in between being ready for the two states
> in which the functionality is NOT by any means ready - and the users
> shouldn't be lied about this - they can't actually use the
> functionality, anyway!
>
>   
>> Some features may be "ready" for both offline and online, that's why I see
>> your point in finishing the operation depending on the state, but this could
>> confuse users. This is the case for SimplePresence. Some "parts" of simple
>> presence are available for offline and some just when you are online, for
>> example availableStatuses is available for offline, and selfPresence is only
>> available when you are online, for obvious reasons.
>>
>>     
>
> Actually, setting self presence should be available in the offline
> case too - that's the whole point of being able to see the available
> statuses. This is to make using invisible/hidden states actually
> useful - so that you won't connect with a default presence, popping up
> as "available" and then after being able to set the presence to
> invisible, going back "offline" - not that invisible, now is it?
>
> Sure, viewing currently set self presence is only available in online,
> but that was removed anyway in the contact-features branch, because
> the user's own Contact's presence provided a more natural way to
> represent that, uniformly with the presence of remote contacts.
>
>   
>> So a solution to this is that, any feature that can be "ready" for both
>> cases (offline and online) should be splitted in more than one feature.
>> Using SimplePresence as example we could have
>> FeatureSimplePresenceAvailableStatuses and FeatureSelfPresence, something
>> like this.
>>
>> So becomeReady(FeatureSimplePresenceAvailableStatuses) should emit finish by
>> the time we have the statuses, no matter if we are online or offline, and
>> becomeReady(FeatureSelfPresence) should emit finish only when we go online
>> and have retrieved all information for self presence.
>>     
>
> Frankly, I don't think this is a very good idea. The same thing
> (available presence statuses) can still be ready for both the offline
> and online state - but with different values! So users DO have to
> consider the offline and online states differently, no matter what we
> do. The point of features should be to group related optional
> functionality - like Presence, which would be the only feature a
> presence chooser applet would be interested in, for example. They
> shouldn't go down to the individual property/function level, and
> definitely not to the "item for a particular connection status" level
> - the functionality of the SimplePresence statuses in the offline and
> online states ARE in fact rather directly related to each other.
>
>   
>> Examples:
>>
>>   Connection *conn;
>>
>>   void connCoreFunctionalityReady(...) {
>>          // now you can use everything on connection, but the ones that
>> depends on features that were not requested and that were requested but are
>> not ready yet
>>   }
>>
>>   void connFeatureSimplePresenceStatusesFinished(...) {
>>         // update UI with possible presence statuses to be set
>>         ...
>>   }
>>
>>   void connFeatureSelfPresenceFinished(...) {
>>         // now you can use the methods to get/set your self presence
>>         ...
>>   }
>>
>>   conn = new Connection(...);
>>   connect(conn->becomeReady(0), finished, connCoreFunctionalityReady, ...)
>> // no features     connect(conn->becomeReady(FeatureSimplePresenceStatuses),
>> finished, connFeatureSimplePresenceStatusesFinished, ...)
>>   connect(conn->becomeReady(FeatureSelfPresence), finished,
>> connFeatureSelfPresenceFinished, ...) // it can be selfContact, just to
>> ilustrate
>>     
>
> No no no no no no no no no no no no no no no no no no no no no no no
> no no no no no no no no no no no no no no no no no no no no no no no
> no no no no no no no no no no no no no no no no no no no no no no no
> no no no no no no no no no no no no no no no no no no no no no no no
> no no no no no no no no no no no no no no no no no no no no
> no.</outburst>
>
> This seems fairly insane to me. You have three callbacks, of which one
> will be called first, sure, but of the other two, they can finish in
> any order, and if the conn's offline, only statuses will ever finish!
> What is for example the previous example of a presence chooser applet
> going to do with a Connection for which only the core functionality is
> ready? And with a Connection for which the presence can be set, but we
> don't yet know WHICH presences exactly can be set? And what about when
> the connection status changes from offline to online? The "ready"
> statuses are now obsolete. To me, the only sensible way to signal this
> would be to first call becomeReady(core and available statuses and the
> ability to set a status) and wait for that getting finished - and
> connecting to statusChanged. When that becomeReady is finished, that
> functionality can be used, whether the Connection was in the offline
> or online state - and if it was offline, they can again be used as
> relevant to the online state when statusChanged(online) is emitted.
>
>   
>>   ...
>> MAY be ready after some feature is already ready. But this at least follows
>> one single path where users just have to call becomeReady once, and when
>> they signal finish, they can use the class methods regarding what features
>> were ready at that time, and this could be documented. We also need to
>> define what core means, so this can change.
>>
>>     
>
> They can't use the methods in the Connecting state whether or not
> their becomeReady has returned in the offline state earlier on or not.
> They can't use them either in the online but not introspected yet
> state, if their value can change from offline -> online (like
> currently EVERYTHING can).
>
>   
>> That's it, as I said, I may be completelly wrong, so feel free to correct me
>>
>>     
>
> I feel you're at least somewhat wrong :P Feel free to disagree with my
> disagreement though. Any other peeps with opinions on how this should
> work? Simon? George? Your input would be appreciated too.
>
>   
Hmm, I now seem to understand your point :). I agree with it

Thanks for the explanation.

BR
Andrunko