Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state

[Milan Crha <mcrha redhat com>]

	Hi,
hmm, I'm afraid I do not follow. It also doesn't seem 'simplified' with
4 different properties. I understand what the current "online" and
"readonly" properties are good for, on both EClient side and backend
side, but I do not understand these four.

On Wed, 2012-04-04 at 13:11 -0400, Matthew Barnes wrote:
> "host-reachable"
> "socket-connectable"

I guess the two above are new and unrelated to online/readonly
properties. They are there to help EBackend subclasses handle their
server reachability, though forcing local backends define values which
might not be necessary, from my point of view. I'm also not sure if I
would use these in CalDAV or evo-mapi, but maybe if I will understand
where this is aiming then I change my mind.

> "readable"
> 
>    type: boolean  perm: read-write  default: false
> 
>    This property is exposed to clients.  It indicates the backend's data
>    is viewable but not necessarily complete, as in the case of a network
>    outage and not having fully synchronized for offline usage.
> 
> "writable"
> 
>    type: boolean  perm: read-write  default: false
> 
>    This property is exposed to clients.  It indicates the backend's data
>    can be modified, but possibly only locally.

Are these two independent or they have an explicit connection between
each other, like if 'readable' is FALSE, then also 'writable' is FALSE?
The "possibly" word in 'writable' property doesn't sound good to me.
What I like on the "online" property is that you know what it means and
you can show some kind of offline icon in the source tree to indicate
that the server is unreachable (vpn down). What icon would you show with
writable? As you cannot distinguish between readonly calendars and
server temporarily unreachable due to reboot/maintenance/vpn down, then
this seems to me quite fuzzy property.

I also do not see the connection between current online/readonly and
these new readable/writable properties, maybe there is none such, but
you may want to define how to change current backends, thus the adopters
will know what to do.

> Clients are responsible for disabling the relevant UI elements when
> this property is FALSE.

I'm not sure if it's the best thing to do. For example in evolution, you
cannot create an event if you have selected a read-only calendar in the
source tree. It's sometimes confusing. While it can make sense with the
inline editing/adding, it may be done differently when choosing
File->New Appointment, where it should claim only when you try to save
it, and inform the user about "you have selected read-only calendar".
You know, the editor let's you change the calendar where to save the
event, thus there might not be a problem with these actions. I can be
wrong here.
	Bye,
	Milan