On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote: > Next part is, that I think network (un)availability and Evolution/E-D-S > online/offline state are two separate things, which got mixed in the > current implementation. Network unavailability means I cannot write my > objects onto the server. In evolution-kolab, whenever a PIM object is > saved, it is first stored in the local write cache. If in "online" > state (as in Evo 2.30 semantics), evo-kolab would then try to push the > object onto the server, which may fail due to a multitude of reasons - > server down, network line shaky (connection dropouts), > firewall-of-the-day is active or whatsoever. The PIM object then simply > stays in the offline cache, waiting for a later successful sync with > the server.
Still not sure how synchronization should be triggered in the UI, but I like the idea of a synchronize() method for EClient. I think being able to explicitly say "synchronize my changes now" is an important use case that we're lacking at the moment. Conflict resolution is a tricky case that to my knowledge we've not really dealt with before. I don't think a UI for conflict resolution necessarily has to be programmed into Evolution. In fact I'd prefer it isn't since it would leave other E-D-S clients out in the cold. Instead the backend itself could spawn off some specialized GTK+ process that pops up a conflict resolution window. Then we wouldn't have to worry about stuffing conflict resolution methods into the client-facing APIs. It would be automatic as far as E-D-S clients are concerned. As for Evolution's forced offline mode feature: at present it only applies to mail since mail is still in Evolution's exclusive domain. Once mail joins address books and calendars as a desktop-wide service with potentially multiple apps acting as clients, I plan to remove Evolution's forced offline mode entirely since it won't be applicable anymore. This is part of my campaign for one E-D-S client to not get special privileges over other E-D-S clients. We need to forget about the 'E' in E-D-S. That said, EBackend's online detection _is_ too simplistic at present. I'd like to make each EBackend determine its own online/offline state by way of g_network_monitor_can_reach(), but I'm holding off on that until my account-mgmt branch is merged, so EBackend will have a consistent way of getting the server address to feed to GNetworkMonitor. Still, seems doable by 3.6. Matt _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
