Am Dienstag 03 April 2012, um 18:05:33 schrieb Matthew Barnes: > 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.
That may be worth it, especially since it is GNetworkMonitor setting this
flag and it is networking-related.
> 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.
Sure, if my backend already knows that the service in question is
not reachable, then no need to try to connect - it could act as if
in "offline" state and just store the PIM object in the local offline
cache. That's all.
> 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?
Not necessarily - the only bit the backend needs to know is whether it is
*supposed* to queue up changes and not try to spool them up onto the server
(this
exactly comprises an "offline" mode, though networking may still be available).
If "network-available" is FALSE, this implies "service-available" to be FALSE -
unless, of course, the service is local, but I do not think you will run a
groupware server on your local client machine with networking down...
If "network-available" changes from FALSE to TRUE, then I think
"service-available"
needs to be re-checked and the flag set accordingly.
> 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.
How about the "service-available" to be set much like the to-be
"network-available",
through GNetworkMonitor, as an EBackend property, which, when changed, emits a
signal?
Just rough thinking, nothing elaborate as yet - I'll be meditating this. :)
Kind regards,
Christian
--
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
