Olli Salli wrote: > On Fri, Feb 6, 2009 at 10:34 PM, Andre Moreira Magalhaes > <[email protected]> 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 _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
