Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
- From: Matthew Barnes <mbarnes redhat com>
- To: hilberg kernelconcepts de
- Cc: evolution-hackers gnome org
- Subject: Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
- Date: Tue, 03 Apr 2012 12:05:33 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]