Re: [Evolution-hackers] Evolution-data-server offline handling
On Fri, 2012-02-03 at 16:58 -0500, Matthew Barnes wrote: > On Fri, 2012-02-03 at 21:27 +, Philip Withnall wrote: > > This sounds good. Do I have to make any fixes to the Google Contacts > > address book backend, or will it all be handled centrally? (i.e. With > > this GNetworkMonitor change, will there be any bugs left in the Google > > backend’s handling of online/offline status?) > > The EBackend base class already has an "online" boolean property. > Backend modules just have to honor it. > > For 3.4 we can just bind it to GNetworkMonitor:network-available if > linking to GLib >= 2.31. > > For 3.6 I'd like to have each EBackend manage its own "online" state by > calling g_network_monitor_can_reach() in response to "network-changed" > signals from GNetworkMonitor. Then we get VPN awareness for free! > > In either case it's all handled in the base class. Here are the patches: https://bugzilla.gnome.org/show_bug.cgi?id=669487 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution-data-server offline handling
On Fri, 2012-02-03 at 21:27 +, Philip Withnall wrote: > This sounds good. Do I have to make any fixes to the Google Contacts > address book backend, or will it all be handled centrally? (i.e. With > this GNetworkMonitor change, will there be any bugs left in the Google > backend’s handling of online/offline status?) The EBackend base class already has an "online" boolean property. Backend modules just have to honor it. For 3.4 we can just bind it to GNetworkMonitor:network-available if linking to GLib >= 2.31. For 3.6 I'd like to have each EBackend manage its own "online" state by calling g_network_monitor_can_reach() in response to "network-changed" signals from GNetworkMonitor. Then we get VPN awareness for free! In either case it's all handled in the base class. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution-data-server offline handling
On Fri, 2012-02-03 at 11:13 -0500, Matthew Barnes wrote: > On Fri, 2012-02-03 at 11:38 +0100, Alexander Larsson wrote: > > IMHO we should implement actual network availibility tracking in > > EDataFactory (using NM or ConnMan) to get the real state inside the > > backends (i.e. if there is no network the backends should always be > > offline). > > Alex and I talked this over on IRC. Summarizing the plan forward here > for the record. > > I had already been salivating over the new GNetworkMonitor API in GLib > 2.31, but hadn't intended to use it until the 3.5 cycle. It means we > can kill the network-manager/connman/windows-sens network detection > modules in Evolution and rely only on GIO from now on. (Finally!) > > But since the situation is so dire for GNOME Contacts, we're going to > utilize GNetworkMonitor in Evolution-Data-Server for 3.4, but only if > linking to GLib 2.31. Alex will supply patches. > > Our minimum GLib requirement will remain GLib 2.30 for GNOME 3.4. This sounds good. Do I have to make any fixes to the Google Contacts address book backend, or will it all be handled centrally? (i.e. With this GNetworkMonitor change, will there be any bugs left in the Google backend’s handling of online/offline status?) Philip > > The question remains however what to do about the forced offline > > state. If you put evolution in forced offline mode, do you truly want > > to turn the desktop-global addressbooks and calendard into offline > > mode too? It might be pretty suprising that suddenly the contacts and > > calendar integration in the shell and contacts is readonly because you > > switched your mailer to offline mode. It can be especially problematic > > if you then close evolution, and have no other place to disable > > offline mode. > > > > Maybe we should make the "offline" mode in evolution really only > > affect the camel_session online state? I don't know exactly what the > > usecase is for the evolution offline mode, so I don't know what the > > best approach is here. > > I agree with this. Evolution's forced offline state should only affect > Evolution, not E-D-S backends. > > So that means, at least while mail is still handled by Evolution, forced > offline state only applies to mail. > > This is consistent with making Evolution "just another E-D-S client" and > not having special privileges over those desktop services. > > Matt > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers signature.asc Description: This is a digitally signed message part ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution-data-server offline handling
On Fri, 2012-02-03 at 11:38 +0100, Alexander Larsson wrote: > IMHO we should implement actual network availibility tracking in > EDataFactory (using NM or ConnMan) to get the real state inside the > backends (i.e. if there is no network the backends should always be > offline). Alex and I talked this over on IRC. Summarizing the plan forward here for the record. I had already been salivating over the new GNetworkMonitor API in GLib 2.31, but hadn't intended to use it until the 3.5 cycle. It means we can kill the network-manager/connman/windows-sens network detection modules in Evolution and rely only on GIO from now on. (Finally!) But since the situation is so dire for GNOME Contacts, we're going to utilize GNetworkMonitor in Evolution-Data-Server for 3.4, but only if linking to GLib 2.31. Alex will supply patches. Our minimum GLib requirement will remain GLib 2.30 for GNOME 3.4. > The question remains however what to do about the forced offline > state. If you put evolution in forced offline mode, do you truly want > to turn the desktop-global addressbooks and calendard into offline > mode too? It might be pretty suprising that suddenly the contacts and > calendar integration in the shell and contacts is readonly because you > switched your mailer to offline mode. It can be especially problematic > if you then close evolution, and have no other place to disable > offline mode. > > Maybe we should make the "offline" mode in evolution really only > affect the camel_session online state? I don't know exactly what the > usecase is for the evolution offline mode, so I don't know what the > best approach is here. I agree with this. Evolution's forced offline state should only affect Evolution, not E-D-S backends. So that means, at least while mail is still handled by Evolution, forced offline state only applies to mail. This is consistent with making Evolution "just another E-D-S client" and not having special privileges over those desktop services. Matt ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
