Re: [Evolution-hackers] Evolution-data-server offline handling

2012-02-06 Thread Alexander Larsson
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

2012-02-03 Thread Matthew Barnes
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


Re: [Evolution-hackers] Evolution-data-server offline handling

2012-02-03 Thread Philip Withnall
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

2012-02-03 Thread Matthew Barnes
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