Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi again, Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg: While porting evolution-kolab from Evolution 2.30 to 3.4.x (and on to 3.5 later on), I have been stumbling upon an issue regarding groupware server synchronzation. [...] Effectively, I am lacking a mechanism which tells my backend that the user wants to synchronize the local cache (evolution-kolab implements a full offline cache with offline-editing support) with the Kolab server side. [...] In our lengthy discussion about that topic, we found that a synchronize() method is desired for the backends and EClient would expose this in its API. How exactly the various E-D-S clients will represent this functionality in their GUI needs to be discussed, but I think this detail is secondary to the former (i.e. the communications infrastructure which makes it possible to send a synchronization request to the backends, which they can then handle in their very own fashion). Have there been steps taken already towards implementing this infrastructure? Kind regards, 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
Hi all, Am Dienstag 08 Mai 2012, um 11:52:00 schrieb Christian Hilberg: It has been a while [0] since the idea of making IMAPX subclassable / extendable for backends to use. Time to bring the topic back into the public again. :-) There is a bugzilla entry [1] now for the topic, and Chen bravely started out with preparations to make IMAPX extendable. [...] While trying to make use of Chen's initial approach to making IMAPX extensible, it has shown that this approach is a little bit too basic and does not lead to the structural improvements inside IMAPX which we've been hoping for. There are some other issues with this approach, too, so we had to rethink the whole thing. As I had made a local copy of IMAPX extensible for evolution-kolab back in 2.30 era using a function table for untagged response handlers, I decided to implement this for upstream IMAPX (while evading some issues I had in 2.30 - live and learn ;-). The result of my work lives in the 'imapx-extensible' branch of E-D-S. It is still work in progress (the IMAP capabilities flags need to be made extensible, too), but it is already working and imapx_untagged() lost most of its amazements. All (IMAPX) devs interested in what has been done so far are welcome to check out 'imapx-extensible' and have a look around in CamelIMAPXServer and friends. Kind regards, Christian [0] http://mail.gnome.org/archives/evolution-hackers/2010-September/msg00012.html [1] https://bugzilla.gnome.org/show_bug.cgi?id=674310 -- 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi, Am Mittwoch 09 Mai 2012, um 09:28:53 schrieb Milan Crha: On Tue, 2012-05-08 at 10:56 +0200, Christian Hilberg wrote: @Milan: Do you think you could post your API work here at e-h list? That would give us something to base our discussion on. Even if no GSoC student picks up the topic, your work should not be lost. Hi, sure, the initial draft is attached. I'm not attaching our conversation around it, as it was long, even it might clarify certain things. As a starter, let's call it EBackendOfflineCache, not as the initial draft calls the base structure EBackendCache. As far as I can tell, it is capable to satisfy all needs from Kolab, I tried to draft it in an extendable way. Has someone been working on this thing yet? Kind regards, 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
On Wed, 2012-06-20 at 10:49 +0200, Christian Hilberg wrote: In our lengthy discussion about that topic, we found that a synchronize() method is desired for the backends and EClient would expose this in its API. How exactly the various E-D-S clients will represent this functionality in their GUI needs to be discussed, but I think this detail is secondary to the former (i.e. the communications infrastructure which makes it possible to send a synchronization request to the backends, which they can then handle in their very own fashion). Have there been steps taken already towards implementing this infrastructure? Not to my knowledge, but I think step one is stubbing in a synchronize() method in EClient and relevant backend interfaces. That much should be easy. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
On Wed, 2012-06-20 at 11:03 +0200, Christian Hilberg wrote: The result of my work lives in the 'imapx-extensible' branch of E-D-S. It is still work in progress (the IMAP capabilities flags need to be made extensible, too), but it is already working and imapx_untagged() lost most of its amazements. All (IMAPX) devs interested in what has been done so far are welcome to check out 'imapx-extensible' and have a look around in CamelIMAPXServer and friends. Thanks for your efforts on this! I still haven't reviewed it closely, though we've discussed it a bit on IRC. I hope to find time to do so soon. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] out of source tree build issue and then installation fails with undefined references in git head
Hi all, Am Dienstag 19 Juni 2012, um 19:55:36 schrieb Reid Thompson: out of tree build requires the following manual intervention... 15001 cp evolution-data-server/libedataserver/*.h obj/evolution-data-server/libedataserver/ 15002 cp evolution-data-server/camel/*.h obj/evolution-data-server/camel/ build will then complete, but installation fails with [...] Same here at E-D-S commit e5c4f3f000d68c3381e0844e50d7e737ae49113f Kind regards, 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 ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Evolution community meeting at #evolution-meet channel - June 20 - 3:30 PM UTC
On Wed, 2012-06-20 at 15:26 -0400, Matthew Barnes wrote: On Tue, 2012-06-19 at 16:03 +0530, Chenthill wrote: As some of you already know, I moved to some other project and spending most of my time there. At-least during the initial period, I would not be getting much time for evolution. Matthew would be taking forward the community meetings hence forth. We decided in today's meeting to end the monthly IRC meetings on account of there being so few Evolution developers left. We agreed this mailing list is sufficient and actually better suited for technical discussions, status updates and upcoming event reminders. We'll hold team-wide IRC meetings as needed henceforth. Discussion of and consensus on this decision is posted here: http://projects.gnome.org/evolution/meeting-logs/2012-06-20.shtml Oh I should have been there. Remembered all the time. Thought of reading a piece of new code before the meeting. It was too much to digest and slept off unknowingly.. Anyways e-h list should be ok as well given the amount of active developers. If any community members wants it, they can still ask for it. - Chenthill. Matthew Barnes ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
