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

2012-02-03 Thread Alexander Larsson
The google addressbook backends only allows writes while online, and I
need to reliably detect this and display the editable state in
Gnome Contacts. The addressbook readonly property is propagated via
folks, so theoretically this should be doable. However, a series of
failures is causing problems for this.

The google backend is looking at e_backend_get_online and
notifications for that property, which gets propagated to
all backends in a single dbus service instance from EDataFactory.

However, EDataFactory looks at the /apps/evolution/shell/start_offline
GConf key, and evolution is not touching this, as it got upgraded
to set the start-offline GSettings key in
org.gnome.evolution.shell instead. This means that no eds backends
will ever see an offline mode atm.

However, even if eds was fixed to read from GSettings this is pretty
bad for Gnome Contacts. The network availible tracking is implemented
as evolution plugins, which require evolution to be running to
propagate network status to the eds backends.

I could duplicate the network manager stuff in gnome-contacts, but
then we run into conflicts if both evolution and gnome-contacts are
running at the same time. This happens because the start-offline key
doesn't purely represent the network_available property, but is a
combination of that and whether the user forced offline mode. For
instance, there is no way for Gnome Contacts to know whether it should
go online again if start_offline=TRUE and we transition from no network
to network availible, because EShell.auto_reconnect is evolution-private
state.

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).

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.


___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers


[Evolution-hackers] [evolution-kolab] IMAPX code dependency

2012-02-03 Thread Christian Hilberg
Hi everyone.

In evolution-kolab [1], we use an IMAPX derivative for accessing
the Kolab groupware server via IMAP.

Since

(a) Camel does not expose IMAPX directly and
(b) IMAPX is not yet cleanly subclassable in all aspects and

I need to keep a copy of upstream IMAPX in the evolution-kolab
source tree.


I need to replicate some code paths of IMAPX (e.g. all paths that
lead from the Store to imapx_untagged, so I can extend this one
for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX
code duplication I cannot avoid at present.

This means that for every (major) change in upstream IMAPX,
I need to pull the changes in and check whether I need to
fix something in my code dupes.

I would therefore be very grateful if anyone who does a major
change or an important fix to IMAPX could give me an advance
warning before pushing into E-D-S master, especially if for any
reason the commit message is not / cannot be prefixed with e.g.
IMAPX: to signify that the change touches IMAPX.
This is especially important to me when (pre)release dates draw
nearer since I would like to keep evolution-kolab IMAPX in sync
with upstream IMAPX for (pre)releases, if at all possible.

Thanks in advance,

Christian


PS.:The changes I do to IMAPX locally at present are not
specific to Kolab (these parts are kepts in yet another
level of subclassing). It is IMAP extensions that I'm
doing, so I'm confident that these extensions will be
pulled upstream one day. Once that happens, and once
IMAPX is exported from Camel for subclassing, I will
happily drop my local copy and the dupes, these will
just no longer be necessary by then.


[1] http://live.gnome.org/Evolution/Kolab

-- 
kernel concepts GmbH   Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


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-kolab] IMAPX code dependency

2012-02-03 Thread Matthew Barnes
On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote: 
 I need to replicate some code paths of IMAPX (e.g. all paths that
 lead from the Store to imapx_untagged, so I can extend this one
 for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX
 code duplication I cannot avoid at present.
 
 This means that for every (major) change in upstream IMAPX,
 I need to pull the changes in and check whether I need to
 fix something in my code dupes.

Would it help you much to turn imapx_untagged() and similar functions
into virtual class methods in CamelIMAPXServerClass?  Then you could
override the method in your subclass, and have it chain up first and
then do other custom stuff.

Or does the logic not allow you to break things out that cleanly at
present?  (wouldn't surprise me)

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 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-kolab] IMAPX code dependency

2012-02-03 Thread Christian Hilberg
Hi Matt,

Am Freitag 03 Februar 2012, um 16:46:50 schrieb Matthew Barnes:
 On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote: 
  I need to replicate some code paths of IMAPX (e.g. all paths that
  lead from the Store to imapx_untagged, so I can extend this one
  for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX
  code duplication I cannot avoid at present.
  
  This means that for every (major) change in upstream IMAPX,
  I need to pull the changes in and check whether I need to
  fix something in my code dupes.
 
 Would it help you much to turn imapx_untagged() and similar functions
 into virtual class methods in CamelIMAPXServerClass?  Then you could
 override the method in your subclass, and have it chain up first and
 then do other custom stuff.

That would definitively make things easier. As far as the CamelIMAPXServer
goes, extending imapx_untagged is the main objective. In fact, for 2.30,
I've added a few more switch cases to imapx_untagged and did no more than
calling one of my own functions there. (I did a little more - we've talked
about that table based approach where I turned almost all of that giant
switch statement into a function table, leaving only a few case's
to be handled - it is all there in evo-kolab's gnome-2-30 branch, but has
never gone upstream).

 Or does the logic not allow you to break things out that cleanly at
 present?  (wouldn't surprise me)

I don't think that my own logic would get into the way here. Now that you've
mentioned it - we were thinking and talking on IRC how to change imapx_untagged
for a table-based approach (a function table that is, with one handler function
per untagged response and its index being the untagged response code). For that,
I think you mentioned a vtable bound to the object (class?), to make the whole
thing extendable.
  I see the imapx_untagged-upcall you mentioned above fit into this scheme.
Extend the vtable, and in your local implementation of imapx_untagged, call
the parent object's imapx_untagged first, then check whether the response has
already been handled (in which case you're done and return), or whether
parent's imapx_untagged tells you that there is a response pending and still
unhandled, so you, the derived class, may have a handler for it. You check, and
yes, you have an entry in your extended vtable for the particular response
code (means, the list of known response codes also needs to be extendable,
that could be a tricky part with the current gperf thing for generating that),
and you call your handler. That is, with the untagged response code, index into
the vtable, get the function pointer and make your call.
  imapx_untagged would be required to set a specific error if the untagged
response could not (yet) be handled. As the implementor of a subclass, after
upchaining to the parent handler, this would allow me to decide whether there
may be work left to do and I can check whether I have a handler for it. If I
do _not_ have a handler, I do propagate that error, so either a subclass of mine
would know that there may be work left to do, or the original caller would know
whether there was no handler for the response code in the inheritance chain.
  Whether or nor a parent's existing handler for a specific untagged response
could be sensibly overridden with this construction might be worth discussing
(or whether it should even be possible - might not be a wise idea to make
that possible).

Dumping a few bits,

Christian

-- 
kernel concepts GmbH   Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/


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 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