[Telepathy] TelepathyQt4: State of the Connection

[Olli Salli]

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.

> BR
> Andrunko
>

-- 

Br,
Olli Salli