On Tue, 2012-04-03 at 17:29 +0200, Christian Hilberg wrote: > Seems to me that opening a connection in order to find out whether I could > open a connection is more than evo-kolab would need. Unless the > "service-available" > check would be really cheap, it seems to me that "host-reachable" would > suffice. Once I actually try to connect and fail, I know that I cannot > connect. Nothing lost. ;-) (What's more, if "service-available" was TRUE half > an hour ago, when the check was made, that does not automatically mean that > it is still TRUE when I want to actually *use* the connection half an hour > later - so, not sure whether a "service-available" check would help much).
Perhaps then simply rename the "online" property to "host-reachable" to clarify it's meaning as a first step? "Online" seems like too nebulous a term in this context anyway. Beyond that you can probably tell I'm flailing around for a coherent story. What I had in mind for "service-available" was a way to notify the client app to just disable certain actions for that account to avoid repeated "Service Unavailable" error messages. But then two questions spring to mind: 1) If a backend can queue up changes offline to be synchronized with a remote server later when it's available again, does that imply its "service-available" flag should remain TRUE always? 2) If a backend CANNOT queue up changes offline, how then should it determine when the remote server becomes available again? Poll? Allow the user to say "try again"? I think I'm lacking insight here, so advice is appreciated. Matt _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
