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-kolab] IMAPX code dependency
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
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
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
[Evolution-hackers] [evolution-kolab] IMAPX code dependency
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
[Evolution-hackers] Evolution-data-server offline handling
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
