Re: [Evolution-hackers] Developing a new protected message complement
Am Mittwoch 02 April 2014, um 19:00:33 schrieb Matthew Barnes: > On Tue, 2014-04-01 at 11:02 -0430, BECERRA Silvana M SIDOR wrote: > [...] > > However, to try to clarify a bit, what we mean by "protected Email" is > > that when reply/forward (inline mode) a "protected message" we're > > allow to write our response but we should not be able to modify the > > text of none of the old messages. Additionally, although not commented > > before, the message should also include custom field in the header > > that consolidates date, from, to, of all old messages in an orderly > > manner. > > For that kind of "protection" to have any real meaning, all messages > should be cryptographically signed by their author and attached in full > to all replies and forwards. An Evolution extension could conceivably > enforce that. > [...] > Cryptographically signing each message with a public key or a trusted > certificate is really the only way to ensure previous messages are not > altered. Might be obvoius: When replying to a message protected that way, the signature for that message should include all attached messages which came with the message replied to. That way, some verifyable "signing chain" would be created. In case of multiple replies to a single message, i.e. a thread, the signature chain becomes a tree (which is verifyable nonetheless). 2 cent, Christian -- kernel concepts GmbH Tel: +49-271-771091-11 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] Move IMAPX back to a module library for 3.12
Hi all, Am Montag 19 August 2013, um 17:47:07 schrieb Srinivasa Ragavan: > On Mon, Aug 19, 2013 at 9:03 PM, Matthew Barnes wrote: > > The IMAPX classes were moved into Camel's public API to serve as base > > classes for evolution-kolab. But since Christian has parted ways with > > us it would appear the evolution-kolab project is no longer active. Sorry for being silent for so long. I was hoping to catch up on schedule with evolution-kolab again, but so far, I have not managed to do so because of being highly loaded with other projects (and evolution-kolab being a spare time project at present, with, alas, no more funding, and very low spare time anyway). As far as Kolab goes, the Kolab people have released a new major version 3, which has the XML storage format changed over the Kolab format version 2, which evolution-kolab currently supports. This would mean to implement a new storage format conversion library for evolution-kolab, which we had planned, but due to budget issues, were not able to implement. > > I'm planning a good deal of API changes to IMAPX over the next few > > months as I work toward completing IMAP NOTIFY support, and I would > > prefer these changes not be seen as breaking Camel's public API so I > > have sufficient freedom to change what needs changed. The IMAPX had been exposed so it could be subclassed and enhanced by evolution-kolab for IMAP-ANNOTATE (Kolab3 uses IMAP-METADATA). In 3.4 times, we had an IMAPX code copy within the evolution-kolab code base, which we got rid of by making IMAPX a Camel public API, so we could subclass it. > > Therefore I plan to move the IMAPX classes back to a runtime-loadable > > module library after the 3.10 release. If the evolution-kolab project > > is resurrected at some point in the future then we can renegotiate this. If by that time, upstream IMAPX can be extended with the aforementioned IMAP extensions, then no need to publicly expose IMAPX again, I guess. > > Any objections? *sigh* Honestly, I cannot really object here, since I do not know when (or even, if) I will be able to resurrect evolution-kolab. From what I can tell reading through the Kolab3 devel list posts, this version of this groupware server seems to catch on better than the previous version did, since they *finally* decided to drop the old OpenPKG distribution format alltogether with Kolab3 and started packaging for distributions. There is, also, still a great need for Kolab clients, although I have not been approached in that regard after evolution-kolab went on a hiatus. > I still dont accept it under Camel. Since we are fixing it, Im fine. > -Srini. Srini, do I get you right in that you do not accept a certain IMAP implementation (IMAPX in this case) being exposed by Camel? I do agree that it somewhat breaks the idea of Camel, that the actual IMAP implementation which gets used should be hidden. When it comes to IMAP extensions, then this concept is somewhat difficult in that it restricts what a certain IMAP implementation can expose feature-wise, and there are some IMAP extensions (like ANNOTATION or, more recently, METADATA), which may make sense to be implemented by, say, IMAPX, but maybe not in any other IMAP code within Camel. evolution-kolab could always resort back to keeping around its own copy of IMAPX, although this would be a nightmare to keep up-to-date. Cheers! I hope to be around more often again in future. Christian -- kernel concepts GmbH Tel: +49-271-771091-11 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] gnome-3-8 branches created
Am Montag 25 März 2013, um 10:59:01 schrieb Milan Crha: > On Sun, 2013-03-17 at 08:47 -0400, Matthew Barnes wrote: > > The master branches are now for 3.9 development. Have at it! > > > > The gnome-3-8 branches are under a code freeze until the 3.8.0 release > > on March 25. > > Hi, > ditto for evolution-mapi. > Bye, > Milan Same holds true for evolution-kolab. Thanks mbarnes for creating the branch. (Bye)^2, Christian -- kernel concepts GmbH Tel: +49-271-771091-11 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] API considerations for avoiding data loss in race conditions
Am Donnerstag 06 Dezember 2012, um 16:13:59 schrieb Christian Hilberg: > Hi all! > > Thanks Tristan for bringing an issue up again which is critical for > PIM software, especially when dealing with groupware servers. > > Am Donnerstag 06 Dezember 2012, um 15:27:49 schrieb Tristan Van Berkom: > > Hello all, > > I'd like to raise this issue on the list for feedback regarding this > > bug: https://bugzilla.gnome.org/show_bug.cgi?id=686684 > > > > First let's start with the basic problem statement: > > ~~ > > > > It can happen that two clients modify the same contact simultaneously, > > or... that one client loads a number of contacts into memory and then > > commits that contact to the addressbook without refreshing the contact > > first, this will result in lost data for the given contact. > > [...] > > Very short note: > > * This issue is not limited to contacts, but can as well hit > calendar (event, task, todo) entries. > > * This issue is also not limited to the EClient<->E-D-S case, > but can occur in the E-D-S<->GroupwareServer case as well > in very much the same way (even without E-D-S offline > capability - the "one has it open for editing while the > other opens, edits, and stores"-case applies also in > online mode if we deal with shared PIM folders). > > To me, this calls for a general approach of how to deal > with PIM synchronization conflicts. Oh, and talking about locks/transactions, please consider this: * EClient starts transaction / acquires lock on PIM entry * E-D-S records transaction start / gives away the PIM entry lock to the EClient requesting * EClient dies for any reason * Started transaction / aquired PIM lock persists in E-D-S What now? Timeout after some time? Welcome back to possible raciness (-->does not truly solve our problem). That same scenario is - again - not limited to EClient<->E-D-S, but can also hit E-D-S<->GroupwareServer. Just 2 cent, 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] API considerations for avoiding data loss in race conditions
Hi all! Thanks Tristan for bringing an issue up again which is critical for PIM software, especially when dealing with groupware servers. Am Donnerstag 06 Dezember 2012, um 15:27:49 schrieb Tristan Van Berkom: > Hello all, > I'd like to raise this issue on the list for feedback regarding this > bug: https://bugzilla.gnome.org/show_bug.cgi?id=686684 > > First let's start with the basic problem statement: > ~~ > > It can happen that two clients modify the same contact simultaneously, > or... that one client loads a number of contacts into memory and then > commits that contact to the addressbook without refreshing the contact > first, this will result in lost data for the given contact. > [...] Very short note: * This issue is not limited to contacts, but can as well hit calendar (event, task, todo) entries. * This issue is also not limited to the EClient<->E-D-S case, but can occur in the E-D-S<->GroupwareServer case as well in very much the same way (even without E-D-S offline capability - the "one has it open for editing while the other opens, edits, and stores"-case applies also in online mode if we deal with shared PIM folders). To me, this calls for a general approach of how to deal with PIM synchronization conflicts. 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] UI interaction from book/calendar backends
Hi everyone, Am Donnerstag 22 November 2012, um 09:13:16 schrieb Milan Crha: > Hi, > the book/calendar backends are currently designed to not have any direct > UI interaction with user, they basically serve for data only. While it > works, it has its caveats, like when user tries to access server using > SSL with self-signed certificate. This should be done like in Camel, > where user is asked what to do, instead of, currently implemented, > checkbox in account preferences for "Ignore invalid certificates". > Another usecase for direct UI interaction is, as xtian suggested some > time ago, when synchronizing offline data to the server, with discovered > conflicts. There might be found more usecases for sure. > [...] Thanks Milan for bringing that up again. Yes, some infrastructure to request for user input from within the backends would be very helpful. We have a dialog ready [0] in evolution-kolab to ask for a user selection from several options they have to solve the conflict. However, this dialog is currently unused in evolution-kolab for the reasons you outlined (and the options set per folder without a possibility for the user to decide on a per-incident-basis how to resolve the conflict). Please see the dialog screenshot to get an idea of what would be needed (I've linked to the dialog screenshot to illustrate the use case). Basically this is * an informative text, with some background highlighting * a number of options for the user to choose from (the id of which to be returned to the backend), the conflict resolution strategy in our case (NB: this could be changed for a radio button list and the typical OK/Cancel buttons) * some setting to be applied to the folder configuration (whether to ask again for the next conflict or to keep the current user selection for the folder and not ask again) Maybe this helps ironing out the requirements for a requester infrastructure. Input fields may also be needed in some cases, although PIN entry is already handled (not sure what else would require text input). Kind regards, Christian [0] http://git.gnome.org/browse/evolution-kolab/plain/docs/dialogs/evo-kolab_pim-sync-conflict-dialog.png -- 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-kolab] using a TPM for SSL/TLS client certs, reloaded
Hi, Am Dienstag 13 November 2012, um 11:18:07 schrieb Christian Hilberg: > Hi everyone. > [...] > GnuTLS, as a replacement for NSS, adds another layer of complication > to the matter. Aside from the TPM user PIN, it requires the higher > level software to locate the correct client certificate for the > connection to be established inside the TPM (or a software emulation > thereof) via so-called "PKCS #11 URIs" in an explicit manner. There This [9] is how that is supposed to work in the latest GnuTLS (support in the 2.12.x series works much the same). Kind regards, Christian > [0] https://live.gnome.org/Evolution/Kolab > [1] https://mail.gnome.org/archives/evolution-hackers/2010-July/msg00076.html > [2] > http://sourceforge.net/projects/evolution-kolab/files/Usage_of_software_security_devices_for_client_authentication.pdf/download > [3] http://sourceforge.net/projects/opencryptoki/ > [4] http://trousers.sourceforge.net/ > [5] http://www.openldap.org/ > [6] http://www.gnu.org/software/gnutls/gnutls.html > [7] https://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 > [8] http://www.openldap.org/lists/openldap-technical/201009/msg00350.html [9] http://www.gnu.org/software/gnutls/manual/gnutls.html#Trusted-Platform-Module -- 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
[Evolution-hackers] [evolution-kolab] using a TPM for SSL/TLS client certs, reloaded
Hi everyone. During the initial implementation of evolution-kolab [0] back in 2.30 days, we evaluated [1] the chances to secure the protocols used to talk to the Kolab server (IMAP, SMTP, HTTP, LDAP) via TLS and having the server request the client to authenticate itself via a client certificate which is retrieved from a trusted platform module (TPM) or a software emulation of a TPM. We got this working for the IMAP, SMTP and HTTP protocols [2], involving the Mozilla NSS library and a PKCS #11 software stack (opencryptroki [3] and trousers [4]). However, we ultimately failed back then to secure the LDAP connection that way. The OpenLDAP [5] protocol library as used in Evolution relies on GnuTLS [6] for transport layer security. In contrast to NSS, GnuTLS requires the library on top of it (OpenLDAP in our case) or the application using both (Evolution in our case) to deal with security details. In order to access a TPM, a user PIN needs to be provided via a callback function. This is all NSS requires, as it handles locating the certificate in an opened TPM all by itself, depending on the connection type and peer. OpenLDAP up to and including version 2.4.25 (and newer 2.4 series, I believe, since this is a stable series) does not support this, and we did not succeed to build OpenLDAP with NSS support proper. GnuTLS, as a replacement for NSS, adds another layer of complication to the matter. Aside from the TPM user PIN, it requires the higher level software to locate the correct client certificate for the connection to be established inside the TPM (or a software emulation thereof) via so-called "PKCS #11 URIs" in an explicit manner. There does not exist an RFC for these URIs, but a draft only, the latest of which [7] expired in September 2012. NSS hides these details, but the OpenLDAP people did not seem to be keen on supporting NSS for transport layer security when we inquired back in 2010 [8]. AFAICT, there has not been a change in that regard so far. My question now (for documenting the status quo) is whether anyone is currently working on getting certificate-based client authentication utilizing a TPM flying in Evolution for OpenLDAP+GnuTLS at present or whether there are any plans to support this use case in the near future. Kind regards, and looking forward to receiving your thoughts on the matter, Christian [0] https://live.gnome.org/Evolution/Kolab [1] https://mail.gnome.org/archives/evolution-hackers/2010-July/msg00076.html [2] http://sourceforge.net/projects/evolution-kolab/files/Usage_of_software_security_devices_for_client_authentication.pdf/download [3] http://sourceforge.net/projects/opencryptoki/ [4] http://trousers.sourceforge.net/ [5] http://www.openldap.org/ [6] http://www.gnu.org/software/gnutls/gnutls.html [7] https://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 [8] http://www.openldap.org/lists/openldap-technical/201009/msg00350.html -- 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] Master branch is now 3.7.1
Hi Matt, Am Sonntag 16 September 2012, um 17:27:15 schrieb Matthew Barnes: > I released Evolution 3.5.92 and co. over the weekend and created > gnome-3-6 branches for the following modules: > > gtkhtml > evolution > evolution-data-server > evolution-ews > > So 3.7 development is now open on these modules. Evolution 3.6.0 and > co. will be released from the gnome-3-6 branch. Thanks. > I defer to Milan and Christian to branch evo-mapi and evo-kolab > respectively when they're ready. The evolution-kolab master branch will stick with 3.6 for a while since there's a lot of work to be done which needs to go into both, 3.6 and 3.8. I have sent a heads-up to the doc/i18n/... lists that evolution-kolab cannot keep up with the string/UI/code freezes this time, and there has not been a negative reply so far. I'm contracted to bring a number of new features into 3.6, which are not finished yet since it took much longer than expected in this cycle just to get the porting done. However, I'm happy that with 3.6.0, we will have a working evolution-kolab(*). :) Thanks to Matt for helping with the porting! > Just a reminder that Milan and I will both be taking personal time off > for the rest of the month starting this week. > > I'll still be somewhat reachable on IRC this Monday and Tuesday but > won't be on the clock, and thereafter reachable by email only until > Monday, October 8th. Matt, I guess it'll be you pushing 3.6.0 out the door, right? (It's just a matter of when to expect 3.6.0 to be out so I can wrap up evolution-kolab for that release). Kind regards, Christian (*) This is, once I get the folder type setting right when creating new PIM folders, which is just a day or two away. Apart from that, new eko is already usable. :) -- 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 3.8 Planning
Hi Matt, Am Dienstag 04 September 2012, um 17:05:36 schrieb Matthew Barnes: > Few quick announcements: > > I started a new planning page on the wiki for Evolution 3.8 and seeded > it with a few items. Would appreciate seeing it fleshed out a bit more. > > https://live.gnome.org/Evolution/Planning38 Thanks for the heads-up. I remember you mention some sort of API restructuring / rework concerning E-D-S, D-Bus and EClients you had in mind for 3.7/3.8 cycle. Do you have anything cooking in this regard already? Might be worth putting on that page. > Milan and I discussed gnome-3-6 branches today. I'm ready to branch and > begin 3.7 development now, but for the sake of translators we'll hold > off until September 17 when GNOME 3.5.92 enters its hard code freeze. Sounds good to me. > Also I'll be taking personal time off the latter half of this month, as > will Milan I believe. So you may be hearing crickets in #evolution for > couple weeks. I'll still have email and will get the 3.6.0 release out > on time. Returning the first week of October. That's some valuable bits of information, thanks. > Matthew Barnes 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] New ECollectionBackend methods
Hi Matt, Am Samstag 04 August 2012, um 13:17:18 schrieb Matthew Barnes: > I finally have the basic framework in place for creating and deleting > folders on a remote server, with a working reference implementation in > Evolution-EWS. > > The new APIs are documented here: > http://mbarnes.fedorapeople.org/account-mgmt/docs/ > > I'll just give a brief overview. > [...] Sounds good, although I do not have much of an overview over this whole infrastructure yet. > [...] > With Evolution-EWS working, I'll be moving on to help Christian again > with Evolution-Kolab next week. > [...] That'll be great. Much appreciated. 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, Am Mittwoch 20 Juni 2012, um 15:32:18 schrieb Matthew Barnes: > 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. Thanks to Matt's courage, the changes from 'imapx-extensible' have already made it into E-D-S 'master'. So far, all seems to behave well. The API for registering new handlers for untagged responses, for registering new capability flags and for sending custom IMAP commands from derivative classes has been implemented but not yet tested. The evolution-kolab plugin will be the first to use this, but it needs to be ported for the E-D-S 'account-mgmt' changes first, which Matt is working on. As soon as this is done, I'll be getting the new IMAPX API live. Any bugfixes needed there should not affect other users of IMAPX. 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] out of source tree build issue and then installation fails with undefined references in git head
Am Donnerstag 21 Juni 2012, um 15:54:07 schrieb Reid Thompson: > On Thu, 2012-06-21 at 10:27 +0200, Christian Hilberg wrote: > > > > E-D-S commit 4bc0fd235298a75bd055f0954fb48748d8dcbdc8 resolves the issue. > > I still am getting the install failure... Did you re-run autogen.sh? 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] out of source tree build issue and then installation fails with undefined references in git head
Hi, Am Mittwoch 20 Juni 2012, um 18:54:26 schrieb Christian Hilberg: > 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 E-D-S commit 4bc0fd235298a75bd055f0954fb48748d8dcbdc8 resolves the issue. 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
Hi Milan, Am Mittwoch 20 Juni 2012, um 19:36:19 schrieb Milan Crha: > On Wed, 2012-06-20 at 11:08 +0200, Christian Hilberg wrote: > > Has someone been working on this thing yet? > > Hi, > I do not know about anyone (current "fires" about account-management > branch merge got higher priority than this, plus I have couple other > bugs pending in my todo before I get free for this thing). I do not know > how much in hurry you are with this. > Bye, > Milan Thanks Milan for the status update, this was the main intent of my asking. Since evolution-kolab *has* as working PIM offline cache, I'm not in a hurry with this (other fires, you know ;-), but if there was some effort going on, I would have liked to participate as much as my own pending todos would allow for. 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] 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] 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] 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 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
[Evolution-hackers] Updating http://projects.gnome.org/evolution/download.shtml
Hi everyone. Each time we release a new version of Evolution, E-D-S and the plugins, http://projects.gnome.org/evolution/download.shtml requires a manual update. New plugins, like evolution-kolab, are easily missed in the process. As for the 3.5 line of evolution-kolab, Matt had even added an entry for evolution-kolab 3.5.1, but commented out, since the porting of the plugin was done only by the time of 3.5.2. By that time, updating of the download page for evolution-kolab got forgotten - again. Even by myself. =) Would not it be better to come up with some workflow which is hooked to e.g. the FTP server where new releases trickle in? The process of updating the download page could even be made automatic - whenever a new release manifests itself on the primary FTP server, the version information is pulled from there and the download page updated. No need to hide Evo's capabilities! :) What do you think? 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] Let's set the date for 3.4.3 release
Hi, Am Montag 04 Juni 2012, um 11:35:14 schrieb Milan Crha: > Hi, > it's after 3.5.2 and I guess we can set the date for 3.4.3 release now. > It'll be the last planned release in 3.4.x cycle, and the sources > contain few fixes for it already (in various core products). The 3.4.2 > happened on May 14th, thus I'm proposing June 18th for 3.4.3, just a > week before 3.5.3. There are still two weeks for changes, in case of > sever bug(s) being found in the stable release. > > Does it work for others? Fine for eko, it is one among the ones with fixes since 3.4.2. 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
Am Dienstag 22 Mai 2012, um 16:38:20 schrieb Christian Hilberg: > [...] > Seems the solution which is now in Git master solves only part > of what is needed (or I am missing something, in which case I > will happily accept correction). Okay, there's another bit missing in current CamelIMAPXServer for it to be generally usable inside CamelIMAPXStore derivatives. Extending the handler for untagged responses in CamelIMAPXServer is half of the deal. Having CamelIMAPXServer expose an API for sending custom IMAP commands from within a subclassed CamelIMAPXStore is the other. In the older evolution-kolab code I've changed CamelIMAXServer to expose imapx_server_command_run_sync(), which was enough for me to send my custom annotation CamelIMAPXCommands for querying and setting IMAP folder annotations. However, this may not be The Right Thing(TM) to do, telling from the code comments in imapx_server_command_run_sync(). We may need to be able to queue CamelIMAPXJobs and wait for their completion. The imapx_server_command_run_sync() approach was simple and sufficient for my few annotation commands, but it may not be good enough for general use. Chen, you know IMAPX a whole lot better than I do, so I'll ask you to expose the right functions for sending custom IMAP commands. 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
And again... Am Mittwoch 23 Mai 2012, um 18:40:34 schrieb Christian Hilberg: > Hi again, > > Am Mittwoch 23 Mai 2012, um 18:05:29 schrieb Christian Hilberg: > > Passing in the user payload data showed to be specifically tricky. > > As dwmw2 just pointed out on IRC, it really isn't. > The data structures which the derivative untagged handlers > need to access can/should best be bound to the derivative > CamelIMAPXServer. In fact, that is exactly the way it works > in my 2.30 approach, only the data structures were not bound > to a derivative, but to the original CamelIMAPXServer. Binding > to the subclass would be the only change needed here. ...which would mean subclassing CamelIMAPXServer. In the currently implemented scheme, CamelIMAPXServer would not be subclassed, but only a handler function registered (which indeed would have trouble accessing the userdata). If we want to subclass CamelIMAPXServer, we also need to modify the connection manager, so instead of the stock CamelIMAPXServer, the derivative class is instantiated and returned when the derivative store object requires a new connection. A working implementation of this can be found in the gnome-3.4 branch [0] of evolution-kolab, though things are somewhat complicated there (CamelIMAPXServer and CamelIMAPXConnManager do not use virtualized functions there, so subclassing meant to re-build the code paths in question - that should be possible in a simpler way with the current 3.5 line of E-D-S). Kind regards, Christian [0] http://git.gnome.org/browse/evolution-kolab/tree/src/camel/providers/imapx?h=gnome-3-4 -- 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 again, Am Mittwoch 23 Mai 2012, um 18:05:29 schrieb Christian Hilberg: > Passing in the user payload data showed to be specifically tricky. As dwmw2 just pointed out on IRC, it really isn't. The data structures which the derivative untagged handlers need to access can/should best be bound to the derivative CamelIMAPXServer. In fact, that is exactly the way it works in my 2.30 approach, only the data structures were not bound to a derivative, but to the original CamelIMAPXServer. Binding to the subclass would be the only change needed here. > Binding the user data to a given CamelIMAPXJob > is also not an option, since it has already been pointed out that > matching the currently active job inside an untagged handler is > problematic (see [0] and [1]). Received correction on IRC. Let that be "should be avoided, if possible", instead of "is not an option". Moreover, as pointed out above, at least for my case, it is not even needed. One issue solved. :) 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 everyone, had a chat with Chen on IRC today about the topic. Since he had to leave, I'll try to sum up our findings here, for the record and for review, please see the inline comments. Am Mittwoch 23 Mai 2012, um 10:00:27 schrieb Christian Hilberg: > Am Dienstag 22 Mai 2012, um 16:38:20 schrieb Christian Hilberg: > > Hi again, > > [...] > > Seems the solution which is now in Git master solves only part > > of what is needed (or I am missing something, in which case I > > will happily accept correction). > > Let me just drop a short summary of what we've come up with so far: > > * The IMAPX tokenizer is not extensible with the current gperf > implementation. New tokens will need to be added for untagged > responses and for server capabilities at least. > > * We need a way to extend the server capabilities flags, so they > will be set according to what the server advertises (for now > it will be ANNOTATEMORE, METADATA and ACL, maybe more) > > * The current *IMAPXExtUntaggedResponseHander (should not this > be "Handler" instead?) function pointer prototype lacks a > possiblilty to pass in and out some user payload data. > [...] > > * The current *IMAPXExtUntaggedResponseHander does not have > a token parameter for me to tell exactly which token has > been read from the stream so I can decide my action It turned out in our discussion that if we followed the current implementation (that of an additional response handler the way CamelIMAPXServer now implements it) would suffer from the above mentioned issues. Passing in the user payload data showed to be specifically tricky. Since the current handler function would need to be able to care for more than one untagged response, passing in the placeholder pointers to payload data (e.g. folder annotation data, which gets processed by the handler function and needs to be put somewhere) would become tricky. Binding the user data to a given CamelIMAPXJob is also not an option, since it has already been pointed out that matching the currently active job inside an untagged handler is problematic (see [0] and [1]). A different approach to making the CamelIMAPXServer extensible and which provides a way to solve all of the issues mentioned above, IMHO is a table based approach for the untagged handler. Each untagged response would be associated a certain handler function (pointer), and these be held in a hash table or somesuch (I guess there are faster ways to do this). The handler functions would then be indexed by the untagged response token ID. A working implementation for this exists in the old (2.30) evolution-kolab version of CamelIMAPXServer, see [2]. It is all there, waiting to be cannibalized and used upstream. This implementation, however, has not been done with extensibility in mind, so that part would have to be tweaked. It would also mean to ditch the gperf approach for generating the token hash tables, since the gperf thing is not extensible. Given a table of function pointers would exist in CamelIMAPXServer, and a function to add more functions, this would solve the extensibility in a neat way. Also, along with added untagged response tokens, there may come added server capabilities (ANNOTATEMORE/METADATA for me, ACL being another candidate, and more out there in the IMAP RFCs), so I would need to be able to register these and have a way to check whether the server advertised the capability or not. Chen asked me for a week's worth of time to look into this. I am convinced that the idea outlined above would be a nice solution, as in the old code, it collapsed the imapx_untagged() function to almost nothing. I would be happy for input - if you see any flaws or if you have good ideas for solving the missing pieces (like, how to pass in and out userdata locations in the handlers in a sane way), please let us know. Kind regards, Christian [0] https://bugzilla.gnome.org/show_bug.cgi?id=676548 [1] https://bugzilla.gnome.org/show_bug.cgi?id=667725 [2] http://git.gnome.org/browse/evolution-kolab/tree/src/camel/providers/imapx/camel-imapx-server.c?h=gnome-2-30#n1363 -- 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
Am Dienstag 22 Mai 2012, um 16:38:20 schrieb Christian Hilberg: > Hi again, > [...] > Seems the solution which is now in Git master solves only part > of what is needed (or I am missing something, in which case I > will happily accept correction). Let me just drop a short summary of what we've come up with so far: * The IMAPX tokenizer is not extensible with the current gperf implementation. New tokens will need to be added for untagged responses and for server capabilities at least. * We need a way to extend the server capabilities flags, so they will be set according to what the server advertises (for now it will be ANNOTATEMORE, METADATA and ACL, maybe more) * The current *IMAPXExtUntaggedResponseHander (should not this be "Handler" instead?) function pointer prototype lacks a possiblilty to pass in and out some user payload data. In evo-kolab, for instance, the ANNOTATION untagged response carries folder annotation data, which I need to insert into a hash table. That means, I would need to pass in a pointer to that hash table. Given the fact that I can only register *one* handler function, which means that in the same handler function I need to process a number of tokens (ANNOTATEMORE and METADATA in my case), which may not share a common data structure to put the payload data into, things will become complicated in the current approach. I would need to pass in a struct, which will be extended with new payload data location pointers each time a new token is added to my handler function * The current *IMAPXExtUntaggedResponseHander does not have a token parameter for me to tell exactly which token has been read from the stream so I can decide my action Seems to me that an extensible table of registered handler functions would not be that much more of an overhead, and as a side effect, it would nicely cut down that nightmare switch statement called "imapx_untagged". :-) 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
Hi folks, Am Dienstag 22 Mai 2012, um 19:04:45 schrieb Matthew Barnes: > On Tue, 2012-05-22 at 16:38 +0200, Christian Hilberg wrote: > > camel-imapx-tokens.txt is the file which is fed to gperf, and the > > resulting structs are used by the IMAPX tokenizer. > > The tokenizer is called inside imapx_untagged, and its result is > > switch()ed on, and the extended untagged handler function, which can > > be registered, is called in the default: block of that same switch > > statement. > > At this point I would advocate ditching gperf and just building an > internal hash table of known tokens which subclasses can extend. I'd second that. > The > tokens could be internalized with g_intern_string() to save a few string > comparisons, but I can't imagine that's a huge performance hit in the > face of network I/O. It would mean one build requirement less, too. > I haven't really looked closely as how gperf is used within the parser, > so this is admittedly hand-wavy. But clearly a static hash function > built from a text file is not going to be extensible the way we need. I had a short look at the gperf docs, and it apparently cannot be fed with several files. Moreover, for gperf being able to build perfect hash tables, it would need to read all of them (the original IMAPX one and all extending ones) at once. Given the IMAPX extensions live in separate modules, this approach would not be maintainable. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
Hi again, finally got my hands on that piece of code now, but see below. Am Donnerstag 10 Mai 2012, um 12:26:51 schrieb Chenthill: > I hope you had sent the mail just before our irc discussion. To > summarize, > https://bugzilla.gnome.org/show_bug.cgi?id=674310#c9 has the fixes. We > now have a hook in imapx_untagged which would allow the subclasses to > handle the responses that are not handled in IMAP (imapx provider). I > did not find a case where a sub-classed imap provider would be > interested in tags which are already processed by the parent imap > provider, so i have provided a simple hook to handle, unhandled tags. I > hope this would be sufficient to support all the above needs. > > Please let me know if you need anything more.. Seems the solution which is now in Git master solves only part of what is needed (or I am missing something, in which case I will happily accept correction). There are at least these issues I see: camel-imapx-tokens.txt is the file which is fed to gperf, and the resulting structs are used by the IMAPX tokenizer. The tokenizer is called inside imapx_untagged, and its result is switch()ed on, and the extended untagged handler function, which can be registered, is called in the default: block of that same switch statement. To make the IMAPX tokenizer aware of new IMAP tokens, these need to be added to camel-imapx-tokens.txt AFAICS. This I did for the 2.30 and 3.4 lines of evolution-kolab, and it worked. I can't see how I should add new tokens to the tokenizer now. The to-be-registered untagged handler function is called after the tokenizer has already run, but without knowing the new tokens this extended handler cares for. What does happen now? Is the new token still sitting there in the CamelIMAPXStream, waiting to be tokenized? Does that mean I need to write my own tokenizer, or duplicate the one already existing in the CamelIMAPXServer? If it was planned that the tokenizer be extended in some way, then the signature of the extended handler is missing the token that the tokenizer has found, so the registered response handler can decide what to do. Next, the tokens I need to care for in the evolution-kolab case are associated with certain server capabilities. Again, for the 2.30 and 3.4 lines of evolution-kolab, I've added new capability flags to the server so I can check that in my own handler function. While that check could, in theory, be omitted, I need it to decide the protocol type for metadata (ANNOTATEMORE or METADATA (planned for)). The same will hold true for IMAP ACL, which will need to implement later on. Unless we can resolve these issues, I am stuck with porting from 3,4 to 3.5, and I've already missed 3.5.1 release (and would not want to miss 3.5.2 as well). This thing is rather urgent. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
Hi, Am Donnerstag 10 Mai 2012, um 12:26:51 schrieb Chenthill: > On Tue, 2012-05-08 at 11:52 +0200, Christian Hilberg wrote: > > Hi everyone! > > > > 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. > [...] > I hope you had sent the mail just before our irc discussion. To > summarize, True. :) > https://bugzilla.gnome.org/show_bug.cgi?id=674310#c9 has the fixes. We > now have a hook in imapx_untagged which would allow the subclasses to > handle the responses that are not handled in IMAP (imapx provider). I > did not find a case where a sub-classed imap provider would be > interested in tags which are already processed by the parent imap > provider, Regarding behavioural consistency, I believe it could even be evil to allow for a subclass to override parent's already-defined behaviour. Not allowing that IMHO is a good thing. > so i have provided a simple hook to handle, unhandled tags. I > hope this would be sufficient to support all the above needs. > > Please let me know if you need anything more.. > > Thanks, Chenthill. I should start playing with that right after the 3.4.2 release. Once I get my hands on the code, I will be able to tell. :-) @Chen: Thanks a lot for your efforts, much appreciated. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi Matt, Am Montag 07 Mai 2012, um 18:17:05 schrieb Matthew Barnes: > On Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote: > > It has already been agreed upon (see previous posts in this thread) that > > such a synchronize() function is needed and that it can be triggered > > from the EClients in a sensible way. Question is, how and when will it > > be implemented so we can test the migrated evolution-kolab parts waiting > > for that. > > Probably someone just has to do it. Unfortunately I'm under heavy > pressure from Red Hat to finish my branch ASAP, so I'm booked solid > until probably early to mid-June. > > Maybe this is something Milan can take up, or even you yourself could > start on the E-D-S side if you're not too busy. Roughing in the new > D-Bus method should be a fairly simple first step. Given that DBus method was implemented, so I could place my sync points there (i.e. call the existing evolution-kolab functions), how could that function be triggered? AFAIK, we do not have an idea as yet how to make that functionality available to the user via GUI. IMHO, a dedicated sync button a user can press in any E-D-S frontend is even more important for typical groupware backends (and the typical use cases they see) than an automated detection of network availability and an online/offline state deduced from that (which is more complicated to implement I think, and it may be hard to keep the user informed of which things are happening in the background). 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Subclassable and extendable IMAPX
Hi everyone! 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. We've been staring at the imapx_untagged() function in IMAPX for a while. This is the handler function which takes care of processing the untagged responses from the IMAP server, and it is the point where IMAP protocol extension code will want to start hooking into. There may be other hooks needed. evolution-kolab uses IMAPX outside Evolution. Back in 2.30 era, IMAPX was not extendable. We thus had the IMAPX code duped and extended the hard way. Since I was overwhelmed by a single function imapx_untagged(), approaching 1k LOC in length, I tore it into pieces (one per untagged response) and added these into a function table. This collapsed imapx_untagged() to almost nothing, looking far more maintainable (and making the function extendable). For those interested in the approach, see [2]. When porting evolution-kolab from 2.30 to 3.4, I decided to try and subclass IMAPX in a clean way, since the 2.30 approach of directly hacking my code into an IMAPX dupe would turn it into a maintenance nightmare in the long run. There are two kinds of extensions to IMAPX I'm doing in evolution-kolab: * IMAP extensions (ANNOTATEMORE, METADATA (planned for), IMAP ACL (planned for)) * Kolab extensions While the latter is Kolab specific, the former is not at all Kolab specific, but holds IMAP extensions as per RFC. It therefore makes sense to strive for integration of these extensions into upstream IMAPX in order to have all users of IMAPX benefit from it. In the evolution-kolab source tree, the former resides in src/camel/providers/imapx while the latter resides in src/camel to make the distinction clear. There are a number of CamelIMAPXExtd* classes I've added to src/camel/providers/imapx which hold my extensions over the upstream IMAPX (the upstream files are duped with just minor changes, mostly exposing internal API for me to hook into). Please see [3] for the stretches I needed to make to subclass IMAPX. Main problem was that imapx_untagged() was not exposed, so I had to re-implement all code paths to that function inside my own extended classes. To ensure I would get my extended object types in the right places, I had to override the CamelIMAPXConnManager classes with my own, mainly because the IMAPX internal classes were not using virtualized functions (which made it impossible for me to just inject my types here and there - I had to make sure the right code paths were followed). The classes in src/camel (thr Kolab-specific ones) look somewhat alike, for that same reason, see [4]. I've not been diving into Chen's proposals very deeply yet. Allowing subclasses to override imapx_untagged() seems like the first step. I've not yet grokked all of the proposals, so I have a question: Will the current proposal (see [1]) allow for a subclassed IMAPX to be subclassed again? Subclassing IMAPX twice is what I'm doing in evolution-kolab. Of course, the first subclassing (for adding support for folder metadata and ACL) can just be dropped, once these extensions make it into upstream subclassable IMAPX. Then, there's my table-based approach to imapx_untagged(). I've been having a chat with Matt about that (and back in the days when I did the implementation for 2.30, with David), which both liked the idea. Of course, my 2.30 implementation was not done with truly subclassing IMAPX in mind, so it would need some tweaking. I'll try to gather more thoughts as I'm rovelling through the code of the proposal at BZ. What do you think? I would invite everyone who is hacking IMAPX to participate in this discussion. [0] http://mail.gnome.org/archives/evolution-hackers/2010-September/msg00012.html [1] https://bugzilla.gnome.org/show_bug.cgi?id=674310 [2] http://git.gnome.org/browse/evolution-kolab/tree/src/camel/providers/imapx/camel-imapx-server.c?h=gnome-2-30#n1363 [3] http://git.gnome.org/browse/evolution-kolab/tree/src/camel/providers/imapx [4] http://git.gnome.org/browse/evolution-kolab/tree/src/camel/ -- 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] PIM server synchronization and Evolution online/offline state
Hi all, Am Dienstag 08 Mai 2012, um 01:11:50 schrieb Philip Withnall: > On Mon, 2012-05-07 at 17:17 +0200, Christian Hilberg wrote: > > Moreover, there's a GSoC project (see > > https://live.gnome.org/SummerOfCode2012/Ideas) > > for a backend cache infrastructure (the Ideas page still outlines > > a Contact cache - is this up-to-date?). > [...] > Unfortunately, there are no GSoC students working on that idea — none of > them showed any interest. :-( > > Milan did some design work on an API for the cache, though I've > misplaced it at the moment. I don't know how this fits in with Kolab's > current cache API, but code reuse is always good. @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. > I will hopefully have some time to work on this in a month or two, if > nobody else has done so by then. My time is really limited up until > mid-June though. Same here, all the more reason not to do double efforts. :) 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi everyone, being back in the office and having cleaned up my desk, let's heat up this topic again, so it hopefully will get us somewhere. Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg: > Hi everyone. > [...] > Back in version 2.30, Evolution has not had a dedicated "synchronize" > button, but there has been the online/offline button, which, when toggled, > resulted in a synchronize() function being called in the cal/book backends. > [...] > In version 3.4 of Evolution, this functionality is no longer existing. Backends other than evolution-kolab may not miss that right now, since (IIRC) none of them implements offline write operations, but all go into read-only mode when offline (please correct me if I'm mistaken). evolution-kolab does miss that, since it already implements full offline write support, which was working in 2.30, but now, the existing functionality cannot be used as before. The following is involved: * CamelIMAPX inside KolabMailImapClient (implements the read-only disk cache for us) * KolabMailSideCache (implements an offline write cache which holds locally changed objects in offline mode and acts as a write-through cache in online mode for PIM objects) * KolabMailSynchronizer (implements collision detection and resolution for PIM objects, used when changing online state as well as in online mode) Unless there is a dedicated synchronize() function with which we can tell the backend to do the synchronization, most of this already-existing infrastructure is not usable in evolution-kolab, but is sitting idle. It has already been agreed upon (see previous posts in this thread) that such a synchronize() function is needed and that it can be triggered from the EClients in a sensible way. Question is, how and when will it be implemented so we can test the migrated evolution-kolab parts waiting for that. Moreover, there's a GSoC project (see https://live.gnome.org/SummerOfCode2012/Ideas) for a backend cache infrastructure (the Ideas page still outlines a Contact cache - is this up-to-date?). Via KolabMailSideCache and KolabMailInfoDb, evolution-kolab already implements an offline cache for both, contacts and calendar types. Albeit being somewhat Kolab-centric at present, this is a working offline cache infrastructure already existing, which could be generalized and/or cannibalized for a new cache usable by all backends (including evolution-kolab). I'd be happy to use a generalized backend cache in evolution-kolab, rather than having each backend implement its own cache, provided evolution-kolab's needs (like being able to store binary blobs) are satisfied. Feel free to ask questions - I'm here to answer them as much as I can. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi, Am Freitag 13 April 2012, um 11:54:51 schrieb David Woodhouse: > On Tue, 2012-04-10 at 21:51 +0200, Patrick Ohly wrote: > > On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: > > > Which is the long-term vision for Evolution in this regard? > > > > Lack of proper offline support has been my main motivation for > > developing SyncEvolution. I know from others that they, too, would love > > to see this supported natively in EDS+Evolution, without the need for an > > external application. > > > > If there is sufficient interest, then I would be open for discussions > > about how SyncEvolution could be integrated seamlessly into Evolution. > > This would bring offline support for CalDAV, CardDAV, ActiveSync and > > might even add support for SyncML peers (client or server). > > I think this could be a really interesting way forward. > > The protocol-specific back ends in Evolution all lack proper > synchronisation support. Their offline operation is read-only, or if > there's offline write support then its capacity for reconciling changes > when it syncs up with the server is very limited. > > We'd definitely want to offer a generic capability within Evolution, for > the various back ends to use to support an offline-writeable mode and > resolve conflicts correctly. Exactly how to detect a sync conflict, and how to act upon one, once detected, is highly specific to the groupware server you talk to. I do not believe a truly generic approach which fits all kinds of groupware servers could ever be finished. ;-) Having a generic mechanism around for dealing with the common aspects of synchronization, however, would do much good. Without having seen SyncEvolution's code base, I guess there are common parts as well as server/protocol specific parts - the latter of which would need to be implemented by the backends, while the common parts (including a mechanism to ask for user interaction while syncing) would need to be implemented only once. But, you may want to bear in mind, that the choices you have in resolving conflicts are dependent on the server you talk to as well. > So, why *not* use SyncEvolution for that, since it can already do it and > it's a *lot* of work to get it right if we were to reimplement it all? Should be fine for the protocols SyncEvolution already supports, at least. > Imagine we ditch Evolution's protocol-specific back ends, and replace > them with something which is basically a local file back end and uses > SyncEvolution (or a derivative/subset of it) to actually communicate > with the server. The different groupware servers do follow their very own paths in how they want to be dealt with. The backends, as I see them now, are mere protocol implementations (or transformers), with offline capabilities attached to them (or not). The groupware server protocols need to be implemented somewhere... not sure whether you could really replace the backends as they are now. Turning SyncEvolution into a common infrastructure which can be used by the backends seems like a more straightforward way to me. > Obviously you'd want changes to be made directly when you're online, "Online" in the sense of "service can be connected to" or "online" as in "client state"? :-) > so > that errors like 'storage full' would be shown immediately. And you'd > want to propagate the storage restrictions (only one mobile number in a > vCard, no ThisAndPrior recurrence exceptions, etc.) to the capabilities > of the particular store. And one or two other details, but I think as a > whole it could work out extremely well. > > I really wouldn't want to see us reinventing the wheel and trying to do > full sync and conflict resolution in Evolution — not in a generic way > for all Evo back ends to use, and *especially* not over and over again That would be very nice, indeed. Still, I have doubts whether you can have a fully generic way of dealing with that, without being forced to make compromises which make it impossible for certain backends to support their respective server capabilities in full. Still meditating on that... 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi, Am Mittwoch 04 April 2012, um 15:09:36 schrieb Milan Crha: > > On Wed, 2012-04-04 at 13:32 +0200, Christian Hilberg wrote: > [...] > > As for evolution-kolab, sadly, there is no good way to do a "quick check" > > for > > changes, at least I do not have an idea how one could implement one, since > > the > > server does not do any kind of bookkeeping for the clients. One can check > > IMAP > > UIDs, any change on them in a PIM folder indicates that a sync is needed, > > but > > you do have to search for the changed objects then. It could slow down the > > open() operation for a cal or book dramatically if the sync was done there, > > that's why I did not put a sync point there for evo-kolab (though it could > > easily be done, but it may create the impression that the cal/book itself > > hangs... and is opening the cal/book cancellable? I don't think so). > > Yes, the whole opening phase is cancellable, and is fully asynchronous > (signal-driven), thus the client says "open me", and it receives > confirmation "your request begun as operation X", then it is waiting for > a confirmation for "I'm (not) opened now", which can come anytime. > Authenticating against the server (asking for a password) is part of the > opening phase. This is there since EClient, thus not for a long time. > You've right having it part of the open itself is too much, that's why > current builtin backends initiate a "delta thread", which takes care of > regular updates (based on the 'refresh' interval) and also possible > upload of changes. Because it runs in its own thread, then there is no > slowdown during the opening phase. Of course, current builtin backends > do not use real offline handling, as far as I know. That's the subject > to change. This approach can be done in async backends, for sync backends it is harder to do. Some behaviour I see in the sync backend classes, to me, creates the impression that sync backends are being phased out and the async ones are the preferred ones. It is true that the async approach has its beauty, but e.g. evolution-kolab is not yet there. It would need to remain a sync backend for some time, there still is internal stuff to be straightened out (I'm trying to do that presently), and evolution-kolab be changed to async only after that (fixing the existing bugs first, then introducing the new ones ;-). Especially for offline-capable backends, the open() operation could return really quickly (using the local cache). Imagine you open() a backend mistakenly (you wanted the other one, really), and the one you mistakenly opened starts its syncing run. Maybe not so nice. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi, ...also re-posting here instead of our more private thread, in order to get these things into public, for the record and for discussion: Am Donnerstag 05 April 2012, um 11:09:37 schrieb Milan Crha: > Hi, > just an out-of-thread idea (initially opened in another discussion): > > Thinking of it, dealing with conflicts while writing changes into the > server when in online mode is simple, the backend just returns an error > and doesn't try to resolve anything. Am I right? It should eventually > update the local object, the only question is when and how (if you > notify clients about change, then the editor will notify user about that > change too - he/she can reject editor update, probably because he/she > wants to use his/her changes and write them to the server, thus still > using the old object). Currently, the evo-kolab backend does conflict detection as well as conflict resolution. The latter mainly since there has not been an infrastructure in E-D-S to request user interaction back in 2.30 era. When configuring a Kolab folder in Evo for PIM use, the user can, basically, select from the following options for sync conflict resolution, which are applied whenever an object is being written onto the server, be it in online mode or while synchronizing after an offline session: * Take newest (relies on the multiple client's clocks to be in sync, since the Kolab server does not help us with that - it just stores mails, and the time when an object is stored onto the server is not necessarily the time when it has been modified - the modicifation could have taken place hours before, while in offline mode, so we need to use the object's modtime here) * Take remote (server side object wins) * Take local (locally modified object wins) * Create dupe (the result is having two distinct objects, local one is assigned a new, collision-free object UID) As soon as the evo-kolab infrastructure for requesting user interaction is ready (will be a temporary solution I think), the above list will contain one more entry: * Always ask (which will pop up a dialog for each sync conflict, in which the user can choose one of the aforementioned four options for resovling the conflict at hand) That's it, basically. For anyone who is interested to have a look at the evolution-kolab sources and the implementation there: The actual cache-implementing object KolabMailSideCache does not have to do anything with all of that, it is on the KolabMailSynchonizer object to decide which object wins and whether a locally cached object will just be dropped and replaced by that of the server, or whether the locally cached one will be written onto the server and after succeeding with that being deleted from the cache. The KolabMailSideCache does not even have a facility to ask what has changed, the bookkeeping for that is done in a KolabMailInfoDb instance. These are all part of the main engine object, KolabMailAccess, and located in the libekolab/ directory in the evolution-kolab source tree. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi there, Am Mittwoch 04 April 2012, um 19:11:46 schrieb Matthew Barnes: > On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote: > > How about the "service-available" to be set much like the to-be > > "network-available", through GNetworkMonitor, as an EBackend property, > > which, when changed, emits a signal? > > > > Just rough thinking, nothing elaborate as yet - I'll be meditating > > this. :) > > We discussed this briefly on IRC, but just to follow up more formally. > > Having stewed on this overnight I think we're coming at the problem > wrong. The question boils down to "can the backend operate on its data > set or not?" That status is as much as we need to expose to clients, I > think. Network availability and remote server availability factor into > the answer but clients need not care. If a backend is offline-capable, > then the answer -- as far as the client is concerned -- is always "yes". This is pretty much how evolution-kolab behaves. From a technical point of view, if the (E)Client knows the backend in question can operate on the given data set, that is simple, sound, and enough for the client to know. What comes to mind is the non-technical, more user-oriented view. Say, a group of users share a common calendar, which, as I outlined before, is a much common use case for Kolab (more common even than private ones), and I guess it is the use case a "groupware" server is all about. Now, if a user edits and saves an event, and my backend says "yes, I can operate on the data" -- what is it the user expects? What she will *see* is, with the above model, that the newly created or changed event got saved. If she is not keenly watching her networking status, she will assume that the event got stored on the server, visible for the others in the group. If the backend, instead, finds, it cannot reach the server, the event will be stored locally and not be visible on the server. The user will proceed with her daily work, assuming the new or changed event is visible to the others in the group, while, actually, it is not. If the backend has no notion of a dedicated "offline" state, and such is not visible in Evolution or any other client, how does the backend tell whether to report an error that the object could not be stored on the server and has been saved locally only, awaiting synchronization? For the backend to be on the safe side, this error would always need to be reported. Say, the user has purposefully disconnected from the network. She will then know that the objects cannot be stored on the server. And she will also know that, once she reconnects, she will need to trigger a synchronization run. On the other hand, while being disconnected (e.g. for a couple of hours or even a few days), she will find it much annoying to be told each time she stores an object that it could not be stored onto the server - "Yes, I know it cannot be stored, as I AM OFFLINE!". This is why I propose a dedicated offline state, which is not dependent on network availability, and which is visible to the user by being displayed in each client that connects to E-D-S. Such a state makes it very clear to both, user and backends, how to act and what to expect during the workflow (for instance, there cannot be any sync conflicts while working in offline mode - the user just plainly does not expect to see any in this case). It also seems that online or offline is not a state the E-D-S clients need to maintain, but it is rather a status E-D-S itself maintains (and tells it to its backends as well as to any client that connects and has the capability to display E-D-S's current status). Once a client requests E-D-S to change online/offline operational mode, the change request can be propagated to both, all backends which do implement a notion of online/offline operational mode, as well as to any client connected to E-D-S which has the capability of showing E-D-S state. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi Milan, thanks a lot for joining us and for writing the nice summary! This is much appreciated. If the mail thread becomes too long and overly complicated, it may make sense to drop the findings into a wiki page and work it out from there. First of all, no, the things discussed here are not going to be easy, and it raises the question what Evolution actually wants to be. Does it want to be a fully offline-capable PIM/groupware client? That means, does it want to support backends which are or strive to be? Which is the long-term vision for Evolution in this regard? Am Mittwoch 04 April 2012, um 12:24:58 schrieb Milan Crha: > On Tue, 2012-04-03 at 13:33 -0400, Matthew Barnes wrote: > > On Tue, 2012-04-03 at 19:10 +0200, Christian Hilberg wrote: > > > Just rough thinking, nothing elaborate as yet - I'll be meditating > > > this. :) > > > > Rough thinking here too. I'll let it simmer. > > Hi, > this thread is getting quite complicated, and I confess I'm rather lost > here (the final outcome should be clear, right). But to summarize which > things are discussed here a bit (or better those I understood): > > a) Add an explicit method to synchronize local changes into the server > b) Add some mechanism to ask user for conflict resolution during a) > c) Tell backend to work in "offline mode" - do no network operations > d) Notify client about current "offline mode" being used by the backend That pretty much sums it up. > -- > > ad a) There is agreed about the method addition, and I agree too. Maybe > a different method prototype would be used (more parameters, see below). > I suppose, you still tries to write the changes to the server as soon as > possible, when in online mode, right? It makes sense, I'm only checking. Trying to bulk-sync as soon as network comes back online may interfere with the user's planned workflow (just reading latest mails on a shaky line), so I would suggest to either leave that to the user (by pressing the sync button), or to provide a config option. The latter could also be done on a per-backend basis. > -- > > ad b) This is quite complicated, the backend cannot rely on gtk+, > because it would bring the dependency on the factory and the factory may > not depend on the gtk+, it should be runnable without live desktop, only > from a terminal. Correct me if I'm wrong. The idea of "another process > taking care of the user interaction" is, apart of quite complicated, > also not easy to do, what if you run the server without live desktop, or > if you run on thin clients, or ... I'm afraid there can be many ways how > to break this approach. Thus, what about adding a DBus signal on the > backend for conflict resolution, something like: >void resolve_sync_conflict ( > guint sync_op_id, > const gchar *server_object, > const gchar *local_object); > which backend will throw and the client side should response through > something like this method: >void sync_conflict_resolved ( > guint sync_op_id, > ESyncConflictResolution resolution); > where ESyncConflictResolution will contain values like: > Unknown > ServerWins > LocalWins > ... (maybe more, Christian may advise better) > Of course, the client part should implement this, which is basically > undoable for all of them (and some even do not use gtk or any user > interaction at all), thus I would add one parameter to the "synchronize" > method, the ESyncConflictResolution value, which will pick the desired > strategy. If it is "Unknown", then the backend can use the signal and > wait for the method to resolve conflicts (better name from "Unknown" > would be "Ask"). Of course, clients without user interface will not call > the "synchronize" method, most likely. > > The resolve_sync_conflict() uses strings for objects, and based on the > EClient type it's either ECalComponent or EVCard as string. You are right, it is too easy to forget that E-D-S better not depend on UI. As for evolution-kolab, if there is no client connected, then no synchronize() action would be triggered, hence no sync conflict would occur. Only if there is a client actually requesting objects or a server synchronization, then the backend would become active and actually *do* something. Otherwise it would be sitting idle and not be trying to keep up with server changes (object changed on server -- backend pulls -- object is changed back on server -- backend pulls --- ... I think a lazy approach would be
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Am Dienstag 03 April 2012, um 18:05:33 schrieb Matthew Barnes: > On Tue, 2012-04-03 at 17:29 +0200, Christian Hilberg wrote: > > Seems to me that opening a connection in order to find out whether I could > > open a connection is more than evo-kolab would need. Unless the > > "service-available" > > check would be really cheap, it seems to me that "host-reachable" would > > suffice. Once I actually try to connect and fail, I know that I cannot > > connect. Nothing lost. ;-) (What's more, if "service-available" was TRUE > > half > > an hour ago, when the check was made, that does not automatically mean that > > it is still TRUE when I want to actually *use* the connection half an hour > > later - so, not sure whether a "service-available" check would help much). > > Perhaps then simply rename the "online" property to "host-reachable" to > clarify it's meaning as a first step? "Online" seems like too nebulous > a term in this context anyway. That may be worth it, especially since it is GNetworkMonitor setting this flag and it is networking-related. > Beyond that you can probably tell I'm flailing around for a coherent > story. What I had in mind for "service-available" was a way to notify > the client app to just disable certain actions for that account to avoid > repeated "Service Unavailable" error messages. Sure, if my backend already knows that the service in question is not reachable, then no need to try to connect - it could act as if in "offline" state and just store the PIM object in the local offline cache. That's all. > But then two questions spring to mind: > > 1) If a backend can queue up changes offline to be synchronized with >a remote server later when it's available again, does that imply its >"service-available" flag should remain TRUE always? Not necessarily - the only bit the backend needs to know is whether it is *supposed* to queue up changes and not try to spool them up onto the server (this exactly comprises an "offline" mode, though networking may still be available). If "network-available" is FALSE, this implies "service-available" to be FALSE - unless, of course, the service is local, but I do not think you will run a groupware server on your local client machine with networking down... If "network-available" changes from FALSE to TRUE, then I think "service-available" needs to be re-checked and the flag set accordingly. > 2) If a backend CANNOT queue up changes offline, how then should it >determine when the remote server becomes available again? Poll? >Allow the user to say "try again"? > > I think I'm lacking insight here, so advice is appreciated. How about the "service-available" to be set much like the to-be "network-available", through GNetworkMonitor, as an EBackend property, which, when changed, emits a signal? Just rough thinking, nothing elaborate as yet - I'll be meditating this. :) 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Memory corruption in timezone handling
Hi, Am Sonntag 01 April 2012, um 11:13:00 schrieb Robie Basak: > Hi freeassociation-devel, > > I think I've tracked down a segfault in evolution to a bug in libical. > > In icaltimezone.c:icaltimezone_get_builtin_timezone, > icalarray_append(builtin_timezones, ...) is called. This can cause > icalarray_expand() to be called, moving the entire builtin_timezones > array and thus invalidating any previous pointers into the array. > [...] A follow-up on the freeassociation-devel list asks whether Evo/E-D-S still use a local fork of libical or whether they're using upstream libical. From what the sources and configure.ac tell me, it is the latter. I guess we should communicate this to freeassociation-devel? 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi Matt, Am Dienstag 03 April 2012, um 17:11:56 schrieb Matthew Barnes: > On Tue, 2012-04-03 at 10:40 -0400, Matthew Barnes wrote: > > g_network_monitor_can_reach() takes a GSocketConnectable -- which is > > just an interface that's implemented by several concrete classes like > > GNetworkAddress (based on host name and port number) and GNetworkService > > (based on SRV records), so I assume service will be taken into account > > when possible in determining the boolean result that would feed into > > EBackend's "online" state. > > Seems I'm assuming too much. > > Dan Winship advises me that g_network_monitor_can_reach() merely checks > if there's a route to the host, but doesn't actually connect. > > Would it make sense to split the "online" state into two flags, perhaps > "host-reachable" and "service-available"? The latter would reflect the > result of actually trying to connect to the service to see if something > answers, obviously only attempted if "host-reachable" is set. > > These could both be class methods in EBackend so backends can tailor > them as needed. For example, an HTTP server may well respond alright, > but with a "501 Service Unavailable" which should interpreted as FALSE. > > Would this distinction be useful to backends? I can only speak for evo-kolab, but that much I will do. Seems to me that opening a connection in order to find out whether I could open a connection is more than evo-kolab would need. Unless the "service-available" check would be really cheap, it seems to me that "host-reachable" would suffice. Once I actually try to connect and fail, I know that I cannot connect. Nothing lost. ;-) (What's more, if "service-available" was TRUE half an hour ago, when the check was made, that does not automatically mean that it is still TRUE when I want to actually *use* the connection half an hour later - so, not sure whether a "service-available" check would help much). 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi Matt, thanks a lot for picking up this topic, as it is quite essential for us. Maybe others can join in as well in order to iron out what would be needed here. Am Dienstag 03 April 2012, um 14:14:52 schrieb Matthew Barnes: > On Tue, 2012-04-03 at 10:52 +0200, Christian Hilberg wrote: > > Next part is, that I think network (un)availability and Evolution/E-D-S > > online/offline state are two separate things, which got mixed in the > > current implementation. Network unavailability means I cannot write my > > objects onto the server. In evolution-kolab, whenever a PIM object is > > saved, it is first stored in the local write cache. If in "online" > > state (as in Evo 2.30 semantics), evo-kolab would then try to push the > > object onto the server, which may fail due to a multitude of reasons - > > server down, network line shaky (connection dropouts), > > firewall-of-the-day is active or whatsoever. The PIM object then simply > > stays in the offline cache, waiting for a later successful sync with > > the server. > > Still not sure how synchronization should be triggered in the UI, but I > like the idea of a synchronize() method for EClient. I think being able > to explicitly say "synchronize my changes now" is an important use case > that we're lacking at the moment. Apart from being rather simple as far as the implementation goes, as I tried to outline in my lengthy posting, there is also a psychological aspect to a dedicated synchronization event triggered by the user: * no surprise if things take time and CPU/network gets hogged, since the operation was explicitly requested by the user * no surprise if sync conflict dialogs pop up * no guessing needed by the backends as to when to trigger a sync run, cals/books stay responsive, no need for possibly quirky workarounds > Conflict resolution is a tricky case that to my knowledge we've not > really dealt with before. In evolution-kolab, we do. We have to, since shared cals/books are common use case (even more common than personal, non-shared ones). We therefore examine our IMAPX cache (all PIM objects are stored as emails in Kolab world) - this is "the server state as it was before". Next, we have our write cache, which - after offline store operations, like creating new objects and changing existing ones - may contain potentially conflicting local changes, and finally the server side, which may contain potentially conflicting remote changes. > I don't think a UI for conflict resolution > necessarily has to be programmed into Evolution. In fact I'd prefer it > isn't since it would leave other E-D-S clients out in the cold. Instead > the backend itself could spawn off some specialized GTK+ process that > pops up a conflict resolution window. Then we wouldn't have to worry > about stuffing conflict resolution methods into the client-facing APIs. > It would be automatic as far as E-D-S clients are concerned. As it is the backend which needs to deal with the conflict resolution, and since it is the backend which needs to actually acquire the user input regarding how to act on the conflict at hand, leaving out Evolution from all this seems to be a good way to do it. I could imagine some service process for this, which backends can use to request user input, in order not to make Evo special among the E-D-S clients. Once the conflict is resolved, the backend can notify interested clients about the change, that's it. Let me once again underline that the current implementation in evolution-kolab with the sync conflict resolution strategy preconfigured per folder (take newer object, take server object, take local object, create duplicate) is a result from the lack of exactly this infrastructure, that a backend cannot request user input in a generalized manner. In real life, these preconfigured resolution strategies will fail to accomodate for what the user really needs (which is a from-case-to-case UI dialog). It is just a mere workaround. > As for Evolution's forced offline mode feature: at present it only > applies to mail since mail is still in Evolution's exclusive domain. > Once mail joins address books and calendars as a desktop-wide service > with potentially multiple apps acting as clients, I plan to remove > Evolution's forced offline mode entirely since it won't be applicable > anymore. This is part of my campaign for one E-D-S client to not get > special privileges over other E-D-S clients. We need to forget about > the 'E' in E-D-S. Make that 'E' an 'Extensible' or 'Elaborate' or whatever, and it will fit again. ;-) > That said, EBackend's online detection is too simplistic at present. > I'd like to make each EBackend determine its own online/offline
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg: > Hi everyone. > [...] > Effectively, I am lacking a mechanism which tells my backend that the user > wants to synchronize the local cache (evolution implements a full offline ^-- evolution-kolab > cache with offline-editing support) with the Kolab server side. If the network > is unavailable and then becomes available, it is debatable whether this would > be a good time to start a synchronization run. > [...] > Kolab server synchronization can become quite bulky, since the Kolab server > does > not have some notion of per-client changesets. It is a mere storage, and > synchronization means to grovel through folders in search of emails. This can > take quite some time, depending on how many objects are stored in a given > folder, > and it can be heavy on CPU usage as well as network bandwidth usage. If that > starts > grovelling just the moment some network becomes available, that can be much > annoying to the unexpecting user. Searching for synchronization conflicts can even involve the necessity to download and unpack MIME mails and parse the Kolab XML part therein, to find out whether a sync conflict actually happened - the server does not help us much with this, it is all on the client. That's one reason why the synchronization with a Kolab server can be bulky. If a sync run gets cancelled or otherwise interrupted, there is nothing we can do but to start over and re-do from start. > [...] 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi everyone. 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. Back in version 2.30, Evolution has not had a dedicated "synchronize" button, but there has been the online/offline button, which, when toggled, resulted in a synchronize() function being called in the cal/book backends. Evo's online/offline state was independent of network availability back then. From a user's point of view, it was okay to have the backend synchronize with the groupware server when Evo online/offline state was toggled. In version 3.4 of Evolution, this functionality is no longer existing. As I learned on IRC yesterday, at least as of GLib version 2.32, the "online" EBackend property is not even toggled by Evolution itself, but by GNetworkMonitor, depending on network (un)availability. If the network is available, the EBackend "online" property is set to TRUE by GNetworkMonitor (via the backend factory), and is set to FALSE once the network becomes unavailable. Effectively, I am lacking a mechanism which tells my backend that the user wants to synchronize the local cache (evolution implements a full offline cache with offline-editing support) with the Kolab server side. If the network is unavailable and then becomes available, it is debatable whether this would be a good time to start a synchronization run. However, if GNetworkMonitor signals network is unavailable, obviously, it is too late to try to synchronize with the server. It has been proposed to use an asynchronous backend thread to synchronize with the server. While it could be done, it has the drawback that during sync, sync conflicts can occur. evolution-kolab presently implements a pre-configurable sync conflict resolution strategy which does not need user interaction during sync, but this was a simplification done in 2.30 since we did not have the capability to ask for user interaction from E-D-S back then. Years of experience with Kolab (and other groupwares) have shown that automatic conflict resolution cannot get it right in many cases and user interaction (manual conflict resolution via a dialog) is needed. Implementation for this has started in evolution-kolab. Back to the topic: A synchronization background thread will run into a sync conflict sooner or later, and a dialog will pop up asking for user interaction. This will inevitably happen while the user is occupied with something else, like composing an email, and it will then disturb her workflow, since she was not expecting some sync conflict dialog to pop up (the principle of least surprise will be violated), let alone the fact that an async synchronization thread introduces a nice extra level of complexity. Kolab server synchronization can become quite bulky, since the Kolab server does not have some notion of per-client changesets. It is a mere storage, and synchronization means to grovel through folders in search of emails. This can take quite some time, depending on how many objects are stored in a given folder, and it can be heavy on CPU usage as well as network bandwidth usage. If that starts grovelling just the moment some network becomes available, that can be much annoying to the unexpecting user. IMHO, you it is a plain impossibility to "guess" the correct time for a server synchronization. As a backend, I do not know what the user wants to do next. Network may be available, but it may be awfully slow (e.g. some hotel room), and the user would prefer to just check some mails and do the heavy groupware server synchronization when back in the office. Some users prefer to work in offline mode, even when networking is available, and do some bulk sync when the time seems right for them. This means that the most simple, most straight-forward and least-surprising (for the user) thing to do would be to invent a dedicated sync button, with which the user can direct the backends to do the server synchronization *now*. Once this button is pressed, it is clear to the user that now, things can take their time and she will be willing to wait for as long as the sync run takes. Depending on network availability, this sync button can even be grayed out - it surely makes sense to deactivate that button if there is no network available (maybe some tooltip could show information why the sync button is deactivated). If networking is available, then the sync button can be pressed. The sync, due to multiple reasons, can still fail, but this is something for the backends to handle. My proposal would be an EBackend virtual function, which the backends can choose to implement and which is called when the user does a dedicated UI action, like pressing a sync button: EBackend::synchronize (EBackend *backend, EDataCal *cal, GCancellable *cancellable, GError *error); That would be one part of the issue. Next part is, that I think network (un)availability and Evolution/E-D-S
Re: [Evolution-hackers] Memory corruption in timezone handling
Hi, Am Sonntag 01 April 2012, um 11:13:00 schrieb Robie Basak: > Hi freeassociation-devel, > > I think I've tracked down a segfault in evolution to a bug in libical. > [...] > Additional notes here, including backtraces of the crash and a valgrind > log catching the access to freed memory red handed: > https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/956843 > http://mail.gnome.org/archives/evolution-hackers/2012-March/msg00028.html FWIW: This might be an issue the evolution-kolab plugin also suffers from [0]. Kind regards, Christian [0] https://bugzilla.gnome.org/show_bug.cgi?id=673197 -- 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] Start your engines for Evolution 3.5.1
Hi everyone, Am Montag 26 März 2012, um 05:03:14 schrieb Matthew Barnes: > You may have noticed Evolution 3.4.0 and co. has been released and I've > created 'gnome-3-4' branches for all modules except 'evolution-mapi' and > 'evolution-kolab' (but I assume Milan and Christian will take care of > those shortly). > [...] As for evolution-kolab, I have a good number of tasks scheduled that would best be done on the current code base (i.e., 3.4), before starting out with new work for the 3.5/3.6 cycle. I'm afraid I painfully lack the resources to cope with both, porting to 3.5 and fixing things in 3.4 (towards 3.4.1), or even merge my work on a 3.4 branch with conflicting fixes which have been done on master in the meantime. I would therefore kindly ask that I branch off gnome-3-4 a little later, providing me with some time to catch up with the fixing and cleanup necessary on the current code base and only after that branching off gnome-3-4. I do not want to keep anyone's hands off of evolution-kolab, thing is, I'll get into trouble if branching will be done early (for 3.5/3.6 cycle I would therefore prefer a late branching for evolution-kolab, "porting" to 3.5 somewhen after 3.4.1). Any thoughts on the topic are welcome. 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 ... 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
[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
Re: [Evolution-hackers] [evolution-kolab] new mailing list
Hi David, Am Dienstag 06 Dezember 2011, um 22:29:46 schrieb David Woodhouse: > On Tue, 2011-12-06 at 17:03 +0100, Christian Hilberg wrote: > > the evolution-kolab plugin now has a mailing list, please see [1]. > > Everyone who is interested in following the discussions there is > > invited to subscribe. I estimate this list to be a low-traffic one, > > at least for some time. :) > > Hm, for EWS I deliberately *didn't* set up a new list; likewise > ActiveSync. I'd rather see it on evo-hackers. When setting up the new list, I had been thinking about this as well. The primary objective is to decommission the SourceForge infrastructure we are still using. This means that we may eventually entirely shut down the old mailing list, archives included, since the archives have been moved to the GNOME.org list as well. A dead mailing list at SF may look like a dead project, that's why I moved it in the first place. I can understand your concern that there may be discussions going astray at evolution-kolab-devel-list, unattended by the rest of the evolution-hackers. This concern is indeed a valid one. I think we can counter this by discussing vital things at evolution-hackers and posting the link into the e-h archive on evolution-kolab-devel-list. What's more, all evolution-kolab devs should be hanging out at #evolution anyway. 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 ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [evolution-kolab] new mailing list
Hi, the evolution-kolab plugin now has a mailing list, please see [1]. Everyone who is interested in following the discussions there is invited to subscribe. I estimate this list to be a low-traffic one, at least for some time. :) I'll post links into the archive of the evolution-kolab-devel-list to evolution-hackers in case of relevant issues being discussed there. Kind regards, Christian [1] http://mail.gnome.org/mailman/listinfo/evolution-kolab-devel-list/ -- 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] UID in vCard
Hi, Am Freitag 18 November 2011, um 16:53:38 schrieb Patrick Ohly: > On Fri, 2011-11-18 at 11:23 +0100, Christian Hilberg wrote: > [...] > > While the E-D-S client (like Evo) might not be interested whether it is > > a Kolab backend being used, there is still one thing you may wish to > > consider here. > > We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our > > backend. > > That should never be necessary. As you said, having such two different > ids doesn't buy the user much. Only a radical step away from "do what > you want with UID" to "UID must be UUID and preserved" will - not > realistic anytime soon, but at least a proof-of-concept would be nice. Writing UIDs as UUIDs only would definitely be a good thing to start with. > > > That is the whole point of this mail thread: a vCard UID may have a > > > meaning outside of the storage in which it currently exists. EDS cannot > > > know whether that is the case. Currently it assumes that the UID has no > > > meaning and throws it away when adding contacts. > > > > Not globally true. The file backend may do so, but it is the backend > > implementation > > deciding whether re-writing a UID or not. E-D-S cannot decide that, since > > it does > > not know what a given backend is dealing with. > > What I meant is the Evolution/EDS API expectation that adding a contact > will never fail because of a UID conflict. Whether the backend > implements that by always overwriting the UID (as the file backend does) > or by keep it when possible and overwriting otherwise (as in the Kolab > backend) is indeed a backend implementation detail. From evolution-kolab's point of view, it would be simple to return a "*mp* UID already exists, try again"-error to E-D-S in that case, provided the E-D-S API for that existed. > But it has the same effect: a libebook user cannot reliably detect an > add<->add UID conflict. It can check for a contact with the UID first > (by assuming that ID in the libebook API == UID in vCard), but then > there's still a race condition between that check and creating that > contact. Again, in Kolab context, the user of the calendar lib or addressbook lib would still get a vague indication only. The race condition could still occur, since there is (a) no transactional system provided by the Kolab server for PIM object creation and (b) any Kolab client is required to fully work in offline mode. While offline, we can check in our local cache whether a UID collision was about to occur and return the corresponding error message to E-D-S. Assume there was no UID collision in offline mode, it may well show up when we're going online again some time later. Imagine, while in offline mode, the PIM object in question has been exported already, carrying the believed-to-be-unique ID, while the object in the offline cache faces a UID collision when being spooled onto the server. Even if we fail to spool that object onto the server since we detected an add<->add collision there, and ask the user for some interaction, we may already have the exported- in-offline-mode-object circulate elsewhere, e.g. by sending it via email, playing funny tricks on us when we try to rely on its "U"UID. As you can see, we can play this game back and forth. AFAICS, the following may be a good start: * have E-D-S generate good UUIDs * give the backends the chance to report if a UUID already exists (if the error does not pop up instantly, it does not mean everything is well, but *if* it does, certainly E-D-S can try again and generate another UID, and notify the user) * encourage all backend implementors not to overwrite existing UIDs, if at all possible Just 2 cents, 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] UID in vCard
Hi Patrick, Am Mittwoch 16 November 2011, um 15:55:54 schrieb Patrick Ohly: > Hello! > [...] > On Di, 2011-11-15 at 15:01 +0100, Christian Hilberg wrote: > > If a new UID is to be created, it is the responsibility of the Kolab client > > to > > assign one. The Kolab server itself is unaware to object UIDs and will not > > touch > > them (no read/write/anything). > With "client", I meant an EDS client here (= the application using > libebook). That there is a Kolab client and server involved is of course > important for you, but not so much for a user of the abstract libebook > API ;-) While the E-D-S client (like Evo) might not be interested whether it is a Kolab backend being used, there is still one thing you may wish to consider here. We could of course map between Kolab PIM object UIDs and E-D-S UUIDs in our backend. The E-D-S client (like Evo) would then see UUIDs and be happy with it. Now imagine someone in Evo exports a PIM object which originates from a Kolab server. Evo would write the E-D-S UUID into that PIM object. Now, by some nice round-trip, this exported PIM object would reach a user of the Kolab server it originated from. By importing the object into the Kolab server, we would then generate a dupe, since the Kolab UID for a PIM object *is* the iCal/vCard UID of an object stored. While this would have the potential of being a self-healing process over time (a PIM object duplication is detected, the one with the UID which is not UUID is deleted), it would take a very long time for the healing to be completed, and only then you could really rely on the assents a UUID makes. To give you a hint about the numbers we're talking about, it is not uncommon for a Kolab deployment to host thousands of contacts and incident types, potentially shared among hundreds of users with various clients. Implementing UUIDs in our backend, as I said, is not an issue. The issue is more like "what to you gain if you cannot rely on the UID you see to be really globally unique". In Kolab context (that's why I'm talking about it here), a mapping between Kolab-UID and E-D-S-UUID would not help you in PIM data exchange and sync interplay. > > > How does the backend work at the moment? Does it always overwrite an > > > existing UID like the file backend does or does it already work as I > > > proposed? > > > > Existing UIDs are (and must be) preserved. This is a requirement for Kolab > > client > > interop, since they all rely on the object's UID to reference it > > (especially regarding > > changes to the contents of the PIM object). In Kolab, there is no way to > > correctly reference an object other than using its UID. > > > > > If it does, do you throw a > > > E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not > > > unique? > > > > Eeewww. :-) evolution-kolab presently sits on Evo/EDS 2.30.3 (which some > > like > > to call "just plain old" here =). No error message in that case. If the UID > > already exists, it gets rewritten. It was a tradeoff here - an existing > > Kolab > > object and its UID superseedes a new one. Imported objects are regarded as > > "new" (being assigned a new UID), should the UID they carry already exist in > > the given PIM folder. The original UID would do no good in the Kolab context > > if another object with that same UID already exists, since other groupware > > clients do have an idea about the object this UID refers to already. Trying > > to find out whether the imported object could actually be an update for an > > already existing one seemed too complex and out-of-scope for the initial > > evolution-kolab implementation. We're now porting to current Evo/EDS git > > master, > > but I would still keep the current implementation unchanged when it comes > > to how to interpret UIDs of imported objects. > > That is the whole point of this mail thread: a vCard UID may have a > meaning outside of the storage in which it currently exists. EDS cannot > know whether that is the case. Currently it assumes that the UID has no > meaning and throws it away when adding contacts. Not globally true. The file backend may do so, but it is the backend implementation deciding whether re-writing a UID or not. E-D-S cannot decide that, since it does not know what a given backend is dealing with. For the evolution-kolab backend, only those UIDs are rewritten which do already exist on the Kolab server. UUIDs would, as a matter of fact, be helpful here. There is *some* risk, however, that by chance you generate a UUID for a PIM object, and may find that even this one exists on the server, because out of full randomness, a UUID-unaware
Re: [Evolution-hackers] Camel no longer depends on libedataserver
Hi everyone. Am Mittwoch 16 November 2011, um 21:38:59 schrieb Matthew Barnes: > On Mon, 2011-11-14 at 23:33 -0500, Matthew Barnes wrote: > > There is no longer any _technical_ reason why Camel needs to be bundled > > in the evolution-data-server module. I DO intend to split Camel off at > > some point, but not yet. Parts of its API are still a complete mess and > > I'd like to give them some attention and also reach some semblance of > > API stability for the library as a whole. We're not there yet. > > Chen asked me in the IRC meeting today [1] to clarify my position on > splitting off Camel. > > My vision for Camel is simply for it to be a nicely crafted, reusable, > well-documented mail client library with tight GIO integration. I do > believe that's in line with what it was intended for all along. > [...] Thanks Matt for detailing your plans. Let me add some lines about what little experience I have with Camel and what we were facing when initially implementing evolution-kolab. Back then (2.30 era), we found we needed an IMAP implementation for use in our backend to talk to a Kolab server. Instead of arbitrarily using some random implementation, naturally, we looked at Camel, since it was provided in E-D-S. When consulting with the people on #evolution, we were instantly pointed to IMAPX, and my thought was "why not". We were, say, surprised when looking at the code. Camel (and IMAPX) sources were located in E-D-S, but used in Evolution, not E-D-S (we did not have a look at other groupware backends at that time). This was some sort of a funny finding to us. Next thing which bit us was the fact that we needed to extend on the existing IMAPX implementation for Kolab specifics. Alas, we found ourselves unable to subclass the Camel IMAP implementation. The reason was clear to us: Camel wanted to hide implementation details, just request your provider for a given protocol and then use it in a unified way. Unfortunately, this did not help us much. We were then forced to duplicate IMAPX in our backend so we have it handy for extension and subsequent subclassing. We did the following: First, extend the IMAPX implementation with the ANNOTATEMORE IMAP extension. It would have been difficult (and the wrong place) to do that in an IMAPX derivative, since this extension is at protocol level. After extending our IMAPX copy that way, we subclassed it to create our own 'kolab2' provider, which has some Kolab-specific extensions above IMAP level (so these extensions are kept outside the actual IMAPX extension). Most notably, the 'kolab2' provider now knows about Kolab folder type annotations, and hides the PIM folders when run in Evo for Kolab email access. When run in the backends, it hides the email folders and the folders the given backend type (cal/book) does not need to care about. So far, so good. Now, we're about to port evolution-kolab to the current 'git master' of Evo and E-D-S. The situation for IMAPX has not changed, so we will need to dupe IMAPX *again*, from current sources, re-implant our extensions into IMAPX (we have not had the time to push them upstream, but will this time, hopefully), and start over. Not during the initial porting, but later on, we will need to extend IMAPX even further, this time with the IMAP ACL support (as far as needed for Kolab, that is). That said, we would not have been able to benefit from Camel being a separate lib, unless it would have exported IMAPX as a subclassable GObject, and we would still have faced the problem that we had to get the IMAP extensions done in time, which we were able to do in our own dupe, but getting the stuff upstream (and doing it really, really Right), would have taken more time than we actually had. The same will hold true for the IMAP ACL extension we have planned. While our code dupe may be a good place to breed some ideas, and let the code mature somewhat, we would be happy of course to see these extensions being moved to IMAPX itself, once the implementation has evolved far enough. We could then get rid of our IMAPX code dupe, ripping it out from evolution-kolab, provided Camel would export the CamelIMAPX* classes as subclassable ones, so we still can derive our CamelKolabIMAPX* classes from them and keep in evolution-kolab only what is truly Kolab specific (like the handling of Kolab folder types). We *would* benifit from Camel being a separate lib, however, in that there be a well- defined and stable API for Camel users. Less API churn, once it has been stabilized, and less effort for Camel users to keep their stuff working. Creating a good and stable Camel API may be a p.i.t.a. initially, but I believe that it will clarify issues that need to be adressed in overall Camel use, which may in turn ease more things in E-D-S and Evo in the long term. I'm not sure how this all would fit together with the planned-for email factory later on, but it might be possible to further freeing evolutio
Re: [Evolution-hackers] UID in vCard
Am Dienstag 15 November 2011, um 15:01:54 schrieb Christian Hilberg: > Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly: > [...] > > What happens during syncing? Do you resolve the add<->add conflict by > > duplicating the item, merging them or discarding one copy? > > This is a configuration option the user has. Kontact, as a reference client > for Kolab, > will ask you in all events of synchronization conflicts. In Evo/EDS 2.30, we > did not > have the infrastructure needed to query Kolab-specific user input from Evo, > so the whole > thing is non-interactive. For each PIM folder, you can configure the backends > to use > one of the following strategies: > * use the "newer" PIM object (relies on timestamps - since these are set by > the clients, > not the Kolab server, it only works if the client's clocks are synced) > * use the client's object (overwrites the one on the server) > * use the server's object (discards the client's changes) > * create a duplicate Adding some more bits: The evolution-kolab user manual has some more info on the current behaviour of the plugin in "3.4.2 Conflict solving strategies", see [1]. Kind regards, Christian [1] http://sourceforge.net/projects/evolution-kolab/files/evolution-kolab_user-manual_v1.3.pdf/download -- 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] UID in vCard
Hi there, Am Dienstag 15 November 2011, um 11:03:24 schrieb Patrick Ohly: > On Di, 2011-11-15 at 10:50 +0100, Christian Hilberg wrote: > [...] > > Just adding a few bits on how the situation is for the Kolab groupware > > server. > > > > The evolution-kolab backend cannot ask the Kolab server for a UID (since > > there > > is no API for that) nor does the server enforce certain UIDs on a PIM > > object (but, > > of course, that there be one). The only requirement is that the PIM > > object's UID > > be unique in a given PIM folder. If the UID is globally unique, all the > > better. > > That's the same situation as with the file backend then: a client could > decide to set a UID in the vCard before creating the contact, and the > Kolab backend+server would use that UID instead of creating their own. > Good :-) If a new UID is to be created, it is the responsibility of the Kolab client to assign one. The Kolab server itself is unaware to object UIDs and will not touch them (no read/write/anything). > How does the backend work at the moment? Does it always overwrite an > existing UID like the file backend does or does it already work as I > proposed? Existing UIDs are (and must be) preserved. This is a requirement for Kolab client interop, since they all rely on the object's UID to reference it (especially regarding changes to the contents of the PIM object). In Kolab, there is no way to correctly reference an object other than using its UID. > If it does, do you throw a > E_BOOK_ERROR_CONTACT_ID_ALREADY_EXISTS when the existing UID is not > unique? Eeewww. :-) evolution-kolab presently sits on Evo/EDS 2.30.3 (which some like to call "just plain old" here =). No error message in that case. If the UID already exists, it gets rewritten. It was a tradeoff here - an existing Kolab object and its UID superseedes a new one. Imported objects are regarded as "new" (being assigned a new UID), should the UID they carry already exist in the given PIM folder. The original UID would do no good in the Kolab context if another object with that same UID already exists, since other groupware clients do have an idea about the object this UID refers to already. Trying to find out whether the imported object could actually be an update for an already existing one seemed too complex and out-of-scope for the initial evolution-kolab implementation. We're now porting to current Evo/EDS git master, but I would still keep the current implementation unchanged when it comes to how to interpret UIDs of imported objects. > > PIM objects already residing on the Kolab server do carry a UID, created by > > the > > client which created the object (evolution-kolab, Kontact, Horde, Outlook > > with > > a Kolab connector, Thunderbird via Lightning/SyncKolab, ...). > > Do you attempt to make the UID globally unique, for example by using a > UUID? In our current implementation, the UID will be unique to the Kolab server at hand. Since the Kolab server does not impose specific restrictions on the format of the UID, evolution-kolab could change the UID generation code (we currently use E-D-S infrastructure for this) to generate UUIDs. However, other Kolab clients are free to follow their very own scheme of UID formatting (they may well decide that UIDs unique for a given folder only are unique enough). I'm not clear whether the new Kolab format specification, which is in the makings right now, would enforce a UID to be globally unique. Older clients would not follow that scheme, so if you cannot rely on the UID of being globally unique, you do not gain anything. The Kolab philosophy is to offload almost everything to the clients for maximum scalability and minimum server load, accepting the fact that the server cannot really enforce anything. The Kolab server itself is, as I said, fully unaware of the PIM data. It stores all PIM objects as emails in IMAP folders. Hence, it will happily accept a client writing multiple PIM emails onto the server and into one PIM folder, all carrying the same UID. It is really all in the hands of the clients. If a new Kolab server will not enforce UIDs to be UUIDs (and it very certainly won't), then your gain is zero if you implement UUIDs in one client only. > > When it comes to importing a PIM object, it is not possible to retain its > > UID in the cases where the same UID exists on the server already for > > another PIM > > object (unlikely, but possible, since Kolab object UIDs are not required to > > be > > globally unique). As long as we're in offline mode, we may at first succeed > > retaining > > the object's UID, but when going online any syncing with the server, find > > that > > a new UID must be set on th
Re: [Evolution-hackers] UID in vCard
Hi everyone, Am Montag 14 November 2011, um 11:22:57 schrieb Milan Crha: > On Mon, 2011-11-14 at 10:00 +0100, Patrick Ohly wrote: > > So I suggest to pursue the first approach instead. I think it is > > possible for the file backend. > > > > Is it also possible for other backends? Or are some unable to store > > the UID and look up contacts (efficiently) by it? In that case we will > > have to relax the semantic of the API and accept that some backends > > still use their own local ID. "Supports UID" should be defined as a > > capability of the backend so that clients can take it into account. > > Hi, > I wouldn't call it "local UID", it's rather "backend's UID" and mostly > not, this is not doable for groupware backends which are using > server-supplied unique identifiers for contacts/calendars, like message > IDs in evolution-mapi, which talks to Exchange servers. It's easier, and > makes sense, to use server-side IDs, which are meant to be unique. > It's also a reason, from my point of view, why > e_data_book_respond_create_contacts() passes UIDs of newly created > objects back to the client. > [...] Just adding a few bits on how the situation is for the Kolab groupware server. The evolution-kolab backend cannot ask the Kolab server for a UID (since there is no API for that) nor does the server enforce certain UIDs on a PIM object (but, of course, that there be one). The only requirement is that the PIM object's UID be unique in a given PIM folder. If the UID is globally unique, all the better. PIM objects already residing on the Kolab server do carry a UID, created by the client which created the object (evolution-kolab, Kontact, Horde, Outlook with a Kolab connector, Thunderbird via Lightning/SyncKolab, ...). An existing UID of a PIM object must be retained, of course. Every Kolab client will follow its own approach creating UIDs. Possible clashes need to be handled by the clients. When creating a new PIM object, the Kolab client needs to create a UID for it. Kolab objects are referenced by folder/UID in evolution-kolab. While mapping between a "E-D-S backend UID" and the "Kolab UID" would be certainly possible, it would require another level of lookups, which has the potential for being inefficient. When it comes to importing a PIM object, it is not possible to retain its UID in the cases where the same UID exists on the server already for another PIM object (unlikely, but possible, since Kolab object UIDs are not required to be globally unique). As long as we're in offline mode, we may at first succeed retaining the object's UID, but when going online any syncing with the server, find that a new UID must be set on the object. No final statement here, just a dump of what came to mind. :-) So here's my 2 cents, 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
[Evolution-hackers] [evolution-kolab] Version 0.30.0 released, moved to gnome.org
Hi everyone! The evolution-kolab team gladly announces the availability of version 0.30.0 of the evolution-kolab plugin for the Evolution PIM suite. The major improvements over our previous release (Version 0.2.1) include overall speedup fixes to most operations as well as a good number of memory leak fixes and internal rework to improve on the user experience. No new functionality has been added. The version number 0.30.0 documents that this is our first true release for GNOME 2.30. Source code, user manual and some supplemental files can be found on the project's old website, located at SourceForge: http://evolution-kolab.sourceforge.net/ The full release announcement can be found at [1]. With this release, active development has been moved away from SourceForge and under the hood of the GNOME project. Thanks to everyone helping with the migration and thanks for the warm welcome at gnome.org. While the migration to gnome.org is still in progress, the Git repository can already be found at http://git.gnome.org/browse/evolution-kolab and a Bugzilla project is being set up. There is a new wiki page https://live.gnome.org/Evolution/Kolab which is to become the new primary source of information for the evolution-kolab project. The current project status and a collection of links to documentation and supplemental stuff are already there, along with some thoughts on the porting of evolution-kolab to the current development branches of Evo and E-D-S, which is now in the makings. Kind regards, Christian [1] https://sourceforge.net/mailarchive/message.php?msg_id=28363963 -- 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] [Reminder] Evolution community meeting at #evolution-meet channel - Oct 18 - 3:30 PM UTC
Hi Chen, Am Dienstag 18 Oktober 2011, um 12:13:04 schrieb Chenthill: > Hi, > The meeting goes as follows, > [...] You sure the meeting is *today*, not tomorrow (i.e. Wednesday), as usual? Just asking. :-) (Bye)^2, Christian -- kernel concepts GbRTel: +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] Camel Authentication Changes
Hi Matthew, Am Montag 17 Oktober 2011, um 23:48:01 schrieb Matthew Barnes: > On Mon, 2011-10-17 at 15:21 +0200, Christian Hilberg wrote: > > Fair enough, thanks for clarifying. If that's the current status, then > > nothing is lost if we keep the implementation as-is for now and try it > > again later on. > > Still not sure how this whole security puzzle fits together yet, but > this sounds like a piece of it: > > http://stef.thewalter.net/2011/10/redesigning-seahorse-experience.html > > Seahorse (or the library stack that Seahorse is built on) is supposedly > adding support for NSS certificates by GNOME 3.4. This reads interesting, for sure. > That means we should soon be able to plug into Seahorse for certificate > management instead of talking to NSS directly some time next year. At > least that's my hope. The email (backend) factory which is in the makings for carving out email handling from the Evo frontend would surely need a way to be fed with passwords, be it standard user auth or any more advanced thing like opening a security token with a PIN and reading authentication data (like client certificates) from there. Once configured in seahorse, Evo might not need to do more than presenting a dialogue for the general seahorse (stack) password, and everything is set from there on, since the email factory, and possibly other factories as well, will be granted access to the passwords or other authentication data they need, all handled by a service which is controlled/configured via seahorse. Maybe this is a perspective for solving that whole security puzzle? > I highly encourage you to contact Stef about your smart card issue, as > he can certainly paint a clearer picture than I can. I will do so. I've seen his posts on gnutls-devel regarding the PKCS#11 stuff, and it really seems things start working out in this area. I'm presently having the issue that OpenLDAP won't use a client certificate, since it builds against GnuTLS, and the security token handling is not transparent there for a lib like OpenLDAP. Instead, the application needs to handle all details by itself. My hope would be that this whole seahorse effort will solve most of the trouble... :) Thanks for the hint and kind regards, Christian -- kernel concepts GbRTel: +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] Camel Authentication Changes
Hi there, Am Montag 17 Oktober 2011, um 14:51:08 schrieb Matthew Barnes: > On Mon, 2011-10-17 at 11:44 +0200, Christian Hilberg wrote: > > I take it this new password API deals with service > > passwords _only_, i.e. service user authentication? > > Correct. I don't have a good answer for you on the security token PIN > use case at the moment. Fair enough, thanks for clarifying. If that's the current status, then nothing is lost if we keep the implementation as-is for now and try it again later on. Kind regards, Christian -- kernel concepts GbRTel: +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] Camel Authentication Changes
Hi Matthew, Am Samstag 15 Oktober 2011, um 17:18:27 schrieb Matthew Barnes: > Just a heads up that I've changed Camel's authentication API to factor > out the password loop that each and every provider currently replicates > for themselves. Turns out they all have the same basic logic flow. > [...] I take it this new password API deals with service passwords _only_, i.e. service user authentication? I'm asking to be sure about this, since I'm still thinking about the passing in of e.g. a security token PIN, be it a CamelService running inside Evolution (for which a PIN dialog implementation exists) or a CamelService running in our evolution-kolab backend (for which we found no clean way when implementing it half a year back). I still do not have grokked enough of the current Evo/EDS implementation and the design plans for the near future to come up with a better solution than the demonstrator we currently have ... which is, to pass the PIN from Evo to the backend via an account configuration detail (which gets stored on disk and therefore is not a solid implementation, but no more than our small, dirty hack around our lack of a better idea at the time we implemented it). Kind regards, Christian -- kernel concepts GbRTel: +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] A little E-D-S code reorganization
Hi there, Am Donnerstag 29 September 2011, um 17:35:04 schrieb Matthew Barnes: > On Thu, 2011-09-29 at 09:13 +0200, Milan Crha wrote: > > I think I mentioned it earlier, and maybe this is the right time, what > > about replacing "e-" prefix with "evolution-" prefix for process names? > > There was a discussion about it some time ago, Chen suggested it, and I > > think it's a good idea. It has a benefit of searching for running > > evolution-related process with one ps command only. I know it's more > > system wide, not only for evolution itself, but because it comes from > > evolution-data-server, then the change makes sense anyway. > > > Okay, okay, you talked me into it. :) > > The "services" directory is in "master" now, with names changed as > suggested. Let me know if you encounter any build problems. Yes, I've encountered them. :) Neither E-D-S nor Evo would build due to missing CFLAGS and LDFLAGS here and there. FYKI and to avoid double work: thanks to Milan, I was able to fix E-D-S (fixes are in master already), work for Evo is underway. Kind regards, Christian -- kernel concepts GbRTel: +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] On porting and extending the plugin
Hi all, thanks to Matt, here are another two which I initially missed (since I was much clear that Camel would move to GObject/GError/GIO...): -- Thread: http://mail.gnome.org/archives/evolution-hackers/2009-November/msg00019.html "[Evolution-hackers] Camel Manifesto" http://mail.gnome.org/archives/evolution-hackers/2010-May/msg0.html "Re: [Evolution-hackers] Camel Manifesto (update)" Objective: * Camel moving from CamelObject to GObject * the former Camel type system is removed * introducing Camel async API * ... evolution-kolab affected classes: * CamelIMAPX* * CamelKolabIMAPX* * KolabMailImapClient * (potentially) KolabMailMimeBuilder -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-July/msg00025.html "[Evolution-hackers] Heads Up: More Camel API breakage in 2.31" Objective: * Camel moving from CamelException to GError * G_IO_ERROR for failable disk/net Camel operations evolution-kolab affected classes: * CamelIMAPX* * CamelKolabIMAPX* * KolabMailImapClient * (potentially) KolabMailMimeBuilder -- -- kernel concepts GbRTel: +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] On porting and extending the plugin
Hi all. Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg: > The evolution-kolab team is currently planning to port the evolution-kolab > plugin to the recent developer version of Evo/E-D-S. I have had a discussion > [...] In order to get a clearer picture of the changes in Evo and E-D-S since version 2.30, I have been groveling through the list postings in search for major changes which will affect the porting (and later extending) of evolution-kolab. I have condensed my findings into a text file which I found might be helpful for others as well, so I'm posting it here. It is evolution-kolab centric of course, and it leaves out all changes which do not affect an E-D-S plugin, also it may not be exhaustive. But hey, you get it free of charge. ;-) Here it is, have fun: evolution-kolab - major Evo/EDS changes since 2.30 created: 2011-09-13 Christian Hilberg changed: 2011-09-14 Christian Hilberg Camel -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-September/msg00037.html "Re: [Evolution-hackers] Camel Manifesto (update)" Objective: * Redefinition of CamelOperation * Rename blocking methods * Asynchronous Methods (new asynchronous API) * CamelStream API change evolution-kolab affected classes: * KolabMailImapClient * everything using CamelStreamMem -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-April/msg00093.html "[Evolution-hackers] CamelService changes" Objectives: * new Camel XDG file system layout * CamelService, CamelSession API changes evolution-kolab affected classes: * CamelKolabSession * CamelKolabStore * KolabMailImapClient -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-June/msg00016.html "[Evolution-hackers] Rethinking Camel settings" Objectives: * introduction of CamelSettings class * settings propagation through Camel classes * plans for "binding mail account settings to ESourceExtensions" evolution-kolab affected classes: * CamelIMAPX* * CamelKolab* -- Evo / EDS (non-Camel) -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html "[Evolution-hackers] Rethinking account management" Objective: * move from GConf to key files (details key file layout) * establish ESourceRegistry (monitoring of config changes) * rewrite of ESource*, API change * connect backend-discovered sources with account evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab -- Thread: http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00054.html "[Evolution-hackers] Account management and keyrings" Objective: * integration of GNOME keyring with the new account management handling * password handling and storing in ESource / EAccount * ESource password API for frontend/backend use evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-January/msg4.html "[Evolution-hackers] Install E-D-S backends into separate directories?" Objective: * separate installation directories for calendar and address book backends * issues with GTypeModule and backend type registering * ESource interferences with GTypeModule (and solving strategy) evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-March/msg00064.html "[Evolution-hackers] Front-end header files for E-D-S libraries" Objective: * create toplevel header files for each E-D-S library * deprecate inclusion of individual lower-level headers evolution-kolab affected classes: * potentially all -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-March/msg00075.html "[Evolution-hackers] Backend requesting arbitrary user input from frontend" Objective: * how to allow backends to ask for user data * case at hand: user PIN (cannot be stored) * signaling from backend to frontend to request for data evolution-kolab affected classes: * ECalBackendKolab * EBookBackendKolab * KolabMailImapClient
Re: [Evolution-hackers] CamelService changes
Hi there, I know it is muc hlate for input, but anyway, here we go: Am Donnerstag 21 April 2011, um 18:43:27 schrieb Matthew Barnes: > To help smooth the way for the account-mgmt I've made a few improvements > to the CamelSession and CamelService APIs in 3.1. It's not necessarily > the *final* APIs that will wind up in 3.2, but more like the first round > of changes leading up to 3.2. > [...] > * The file storage location for CamelServices (really only CamelStores) > has changed. It is now simply: > > $(XDG_DATA_HOME)/evolution/mail/$(UID) > > rather than: > > $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) > > That means each CamelService has a permanent location for files that > doesn't change if the user tweaks server settings or even changes the > provider. > [...] I recall that when I tried to find my way into Camel when using it from within the backend processes for evolution-kolab, I screwed up my provider directory (named 'kolab2' in 2.30) now and then because of wrong Camel use. It was then very easy to recover from the error by just killing my own provider's subdirectory, which was easy to identify (let alone all of the downsides the historic approach may have). Please forgive me for not reading the Camel code here - can one guess from the UID to which account it may belong? What's more, in the current evolution-kolab design for 2.30, we have $(XDG_DATA_HOME)/evolution/mail/$(PROVIDER_NAME)/$(URL) $(XDG_DATA_HOME)/evolution/calendar/$(PROVIDER_NAME)/$(URL) $(XDG_DATA_HOME)/evolution/addressbook/$(PROVIDER_NAME)/$(URL) since we're using CamelStore also in the backends. Hope this will not prove a broken design with the new situation for Camel. Moreover, our pimped IMAPX derivative uses further SQLite databases in addition to the folders.db Camel creates. These are for Kolab metadata and for an offline write cache for Kolab PIM data. The PIM data cache is used in backend context only, while the Kolab folder metadata DB is used by the kolab2 provider run in Evo as well. I hope that changing forth and back the providers for an account will not mess with that. (The Kolab metadata DB is re-created and re-populated in case it is missing, so it should not be problematic during migration.) Kind regards, Christian -- kernel concepts GbRTel: +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] Rethinking account management
Hi, Am Dienstag 18 Januar 2011, um 20:32:44 schrieb Matthew Barnes: > [...] > Now I'll let you in on my master plan: > > Either in the 3.2 or 3.4 time frame, after the branch is merged and has > some time to settle in and stabilize, I want to move these configuration > dialogs to Evolution-Data-Server and also write some simple command-line > tools to run the dialogs. > > Doing his will finally make it possible to configure address books and > calendars for E-D-S independently of Evolution. With that in place, we > can start adding some nice desktop integration. Has there already been a manifestation of that Evo-independent backend configuration? Kind regards, Christian -- kernel concepts GbRTel: +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] On porting and extending the plugin
Hi Milan, Am Mittwoch 14 September 2011, um 08:25:20 schrieb Milan Crha: > On Tue, 2011-09-13 at 15:56 +0200, Christian Hilberg wrote: > > * IMAP ACL management. A new tab (or something alike) when > > right-clicking an IMAP folder in the Evo folder tree to view and > > edit IMAP access control lists as defined in RFC 4314 [4]. The IMAP > > ACL functionality will be implemented on a new branch based on A-B > > (see "Phase I, (1)"), much the same way ANNOTATEMORE has been > > implemented, to the extend needed for Kolab. This will lead to an > > API extension (like there already is in evolution-kolab-IMAPX). > > There will be the need to extend Evolution as well, as to make it > > use this API extension. It is currently not yet planned exactly how > > this can be done without littering Evolution with "the tacking on of > > arbitrary features" (MBarnes, [3]) > > (Kolab specific: no) > > Hi, > see how evolution-exchange provides the same functionality of Folder > Permissions, it just adds a popup menu item and servers all what is > needed without any special modification on evolution side. The same > should apply for the folder type annotation editing - no change on > evolution should be needed. I'll check that. The less change needed on Evo side the better. I'm not sure yet exactly how we will be able to solve it. I do not have knowledge about how folders are handled in Exchange, but for Kolab, it is IMAP - so we need the capability for IMAP ACL, which, unless I'm mistaken, IMAPX does not yet provide. This part will be done (for now) in our IMAPX derivative, and Evo will need to make use of this functionality one way or another. ACL management is not limited to the evolution-kolab backends and is needed for the Kolab email folders (which are plain IMAP folders) as well. Maybe we can do this in an EExtension, I'll check with evolution-exchange. If the UI extension evolution-exchange provides is fine for the Evo community (which I think it is), then we could try to mimick the layout in order to try for a consistent user experience. To that respect, maybe it will be possible to iron out some common approach for the groupware plugins that way, which I think is what Matt has in mind. > With respect of creating a new folder on the kolab server other than > mail: when you do File->New->Calendar and select the Kolab group, is it > able to create a new folder and annotate it accordingly to the source > group? Evolution-mapi provides a short folder list with folders of the > certain type from which user can choose and under this is created the > new calendar (or address book). Again, no change on evo side is needed > for this. As far as creating new PIM folders goes, this is correct. This can be done entirely in the backends, provided we can re-use existing account information (which in current Evo/E-D-S should be possible). Things are different when you need to change or set the type of an existing folder manually. This is for error recovery mainly, but has been described by our sponsor as a real life scenario which from time to time happens to occur (due to server failure or client error). To do this, it will be made possible to display the PIM folders in the email folder tree (though these folder's contents will not be accessible), so you can right-click the folder and edit the annotation it carries by selecting a type from a drop down list. This is the typical way Kolab clients will provide this functionality for the user. There are a number of issues related to this, e.g. the kolab backends need to be notified of the change do they can sort of "drop" a folder they are no longer supposed to care for ... whether or not we can sanely implement this remains to be seen. The goal behind this is to enable Evolution to act as a complete Kolab client, removing the need to resort to different clients to get all tasks done. Kind regards and thanks for the hints, Christian -- kernel concepts GbRTel: +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] On porting and extending the plugin
Hi again, one more thought: It would be nice from my developer's point of view if it was possible to do the UI extensions via some extension mechanism like EExtension, which would speed up the implementation process for me. However, Matt has a point when he says (in [3]) that he does not want Evo to decline into some "tacking on of arbitrary features" kind of user experience. The question here is whether such an UI extension could still be done as an EExtension or should it rather be implemented in Evo itself. Kind regards, Christian Am Dienstag 13 September 2011, um 15:56:00 schrieb Christian Hilberg: > [...] > [3] > http://mail.gnome.org/archives/evolution-hackers/2011-September/msg00030.html -- kernel concepts GbRTel: +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-kolab] On porting and extending the plugin
Hi everyone. The evolution-kolab team is currently planning to port the evolution-kolab plugin to the recent developer version of Evo/E-D-S. I have had a discussion on IRC with Matt, David and Milan about some aspects of the current developments in Evo and E-D-S, and how they may impact the porting and extending of evolution-kolab. Your input on my thoughts is much welcome. Our resources are pretty much limited - again - and I will need to keep a keen eye on the time I can spend on the different work packages. This will result in suboptimal design decisions here and there, much as with the initial project. That's most of a pity, but there is nothing I can change about it presently. We will, however, try to align our design decisions as much closely as possible with upcoming upstream changes. So far, I have identified two main phases of this undertaking: Phase I: Porting evolution-kolab from Evo/E-D-S version 2.30 to the current git master. No functional extending will take place here, the effort will be to just get things working the way they do under 2.30. For the whole porting process, I will not be able to spend more than the one mythical man month. Phase II: Extending the evolution-kolab functionality in conjuction with some Evolution UI extensions and use of the currently-developed new infrastructure components in Evo and E-D-S. This part has not yet been fully thought through, but everything I see so far here depends on the first phase having been completed successfully. The following is planned for the two phases: Phase I: Porting * Create a new 'evolution-kolab' git repo on git.gnome.org, alongside the other E-D-S groupware plugins (preparations for doing so are completed) * Transfer the contents of the current SourceForge evolution-kolab repo to git.gnome.org. The SourceForge repo will be kept for bugfixing the 2.30 version, but no further development there * Start off with the porting work on the git.gnome.org repo The porting itself will be done in the following steps: (1) Adapt the Camel IMAPX provider used for evolution-kolab to the upstream version. This basically means to * Create a clean branch (say, A) into which to commit upstream IMAPX * Branch off of A (creates branch A-B), and re-implement the draft IMAP ANNOTATEMORE [1] extension (RFC 5464 [2] is what the ANNOTATEMORE draft finally evolved into, but current Kolab 2 servers use version 05 of ANNOTATEMORE) as it was done for 2.30, but using clean branches. In case of upstream IMAPX fixes, these will be applied onto A and A-B rebased, so a clean patchset can be generated with these two branches * The really clean way, i.e. doing this upstream directly, cannot be pursued right now since Camel does not export IMAPX, and evolution-kolab needs to subclass the extended version of IMAPX for the Kolab-specific parts (changing Camel to export IMAPX will be taking too much time for this project to do it ourselves - same problem we had when initially implementing evolution-kolab) (2) Subclass the locally extended IMAPX provider to add the Kolab-specific bits to it * For the curious, see the src/camel/ directory of evolution-kolab and how it relates to src/camel/providers/imapx/) * Once done, the new 'kolab2' provider can be tested with Evolution frontend (3) Adapt the backends glue code to the new E-D-S infrastructure * This will most likely include switching to a fully asynchronous implementation for evolution-kolab (which is presently a synchronous backend but uses notifications here and there anyhow) (4) Port the existing EPlugin account setup and Kolab folder configuration dialogs * As Matt suggested in [3], we will be sticking with EPlugin for the account stuff for time being * Since evolution-kolab needs Camel configuration details in the backends, we're not sure how this will fit with the new ECredentials framework or the account management infrastructure Matt is working on Phase II: Extending functionality This phase has not yet been planned fully. Phase I needs to be concluded successfully before this phase can start. The following is planned, more may follow: * Tooltip extension of the free/busy dialog. Kolab2 supports extended free/busy lists, which evolution-kolab can already retrieve. If extended f/b information is available (typically, this is the event subject) for a certain user, moving the mouse pointer over a time slot marked as busy, the extended information will be displayed as a tooltip window (Kolab specific: no, but needs extended free/busy information (XFB)) * Group meeting attendee busy warning. When scheduling a group meeting and free-busy information is available, the user can opt to receive a warning if any attendee of the meeting is busy during the time the new meeting is going to be scheduled for (this is, when trying to submit the new meeting entry). It will be possible to ignore t
Re: [Evolution-hackers] Evo/E-D-S security (libs) long-term plans
Hi Milan, Am Dienstag 13 September 2011, um 15:30:20 schrieb Milan Crha: > [...] > Hi, > ECredentials is used with "authenticate-user" callbacks now. Check its > usage in ECalBackend/EBookBackend sources, with the comments there. I > [...] Thanks for the pointer, will check that. Kind regards, Christian -- kernel concepts GbRTel: +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] Moving EExtension to libedataserver
Hi Matthew, Am Montag 12 September 2011, um 16:04:23 schrieb Matthew Barnes: > [...] > To answer your second question, menus and dialogs _can_ be extended via > EConfig without relying on XML files, but it's a little more cumbersome. Probably we should not head down the EConfig route, since in [1] you say that, "The new dialog windows will [...] NOT use EConfig. Not using EConfig is a *feature*. Means we're a step closer to killing it." Seems EConfig would not be that much of a stable ground anyone should settle on. :-) Kind regards, Christian [1] http://mail.gnome.org/archives/evolution-hackers/2011-January/msg00013.html -- kernel concepts GbRTel: +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] Evo/E-D-S security (libs) long-term plans
Hi Milan, Am Dienstag 13 September 2011, um 07:33:31 schrieb Milan Crha: > On Mon, 2011-09-12 at 13:16 +0200, Christian Hilberg wrote: > > We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. > > > > These are protocols handled by Camel and the underlying NSS library. In > > order to access the crypto token, we needed to supply a token PIN, which > > we were not able to pass from Evo to E-D-S in version 2.30 as "live" > > data (pass-and- forget). So we had to use a fake implementation: we > > store the user PIN along the rest of the account data and reading it in > > the backend via ESource. Clearly, this violates security (and we are > > saying to in our user manual), but it demonstrates that in principle, > > things are working. To get this thing right, we would need a means to > > ask for a security pin from within the backend, presenting a dialog to > > the user > > Hi, > with the current eds (upcoming 3.2.0) you can pass parameters via > ECredentials, same as you do with e_passwords_ask_password, thus yes, > this is doable from book/cal backends now too. Hum, is ECredentials something a backend can actively request? With NSS, we need to register an NSS callback function in our backend, which is called by NSS when NSS tries to open the token for the first time in the session. Since the token PIN should not be stored anywhere (and removed from memory once the token is opened), the callback function will be the one triggering a user dialog to be opened, the PIN entered, passed to the callback function and set in NSS. After that, the whole dialog stuff will be closed and gone. At least, that would be the right way of doing it. It's not a hard requirement for us now (politics have changed a little), but there may be similar requirements coming from other backends, so I thought of bringing this issue up. And if we get the functionality for little money, we can make use of it. > > However, there is one protocol, for which we failed to implement any > > demonstrator for client-certificate-based authentication using a hardware > > crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as > > a protocol implementation, which in turn uses GnuTLS for security > > (version 2.1x < 2.12 at that time). > > The OpenLDAP 2.12 is kinda old. And if I recall correctly, they moved to > NSS as well, at least 2.4.23 seems to use NSS based on their changelog. > Thus, I would say, when you move to current eds, then you can be pretty > sure that the used OpenLDAP will be the one with NSS. Or you can add a > dependency to evolution-kolab on the OpenLDAP which fits you best. Oops, sorry -- I missed to clarify this better. The LDAP access (for addresses) I was talking about is the one implemented in Evo itself, not the backend variant. There, we hit the aforementioned problem. Maybe the new OpenLDAP with NSS support will enable us to do what we need, since Evo already provides infrastructure for requesting security PINs. Thanks for the hint! Kind regards, Christian -- kernel concepts GbRTel: +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] Further thoughts on ESources
Hi all, Am Donnerstag 25 August 2011, um 18:46:15 schrieb Matthew Barnes: > [...] > Proposal: > > I think the key file management needs to be centralized in a new D-Bus > service, tentatively called "e-source-registry". The ESourceRegistry > singleton class in client programs would then be a proxy for the D-Bus > service. So we'd have a bit of a D-Bus hierarchy: > > >evolution and other e-d-s clients > > e-addressbook-factory | e-calendar-factory > \ | / > e-source-registry Are there plans for any sort of "live service" implemented by this (or yet another component), so that e.g. a backend implementation can query for user input when it needs it? The use case I have in mind originates from the problem we are facing in evolution-kolab backend processes, that we cannot ask for a security PIN (which should not be stored anywhere, but be used-and-forgotten) when opening a security hardware device for a session. If you see Evolution as any one of possibly multiple clients to E-D-S, then it probably makes no sense to pop-up any *Evo* dialogue to ask for the PIN. This would make Evo an even more privileged E-D-S client than it currently is, while my understanding of the current development seems to be to rid Evo of it's privileged status and turn it more into a yet-another E-D-S client. For the problem at hand, we would most probably need some dumb input dialog to pop up, requesting the token PIN, and be gone again - the way security tokens should be used mandates their PIN not be stored *anywhere*, not even in a gnome-keyring or services like that... so I'm curious which plans may exist here (or may need thought-smithing ;-). Kind regards, Christian -- kernel concepts GbRTel: +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] Evo/E-D-S security (libs) long-term plans
Hi all. During the initial implementation of the evolution-kolab plugin, we were concerned with using hardware crypto devices (TPM, trusted platform module) as a means to store and retrieve client certificates for securing TLS connections to a Kolab server (by configuring the Kolab server to require certificates for client authentication). We succeeded doing so for the following protocols: HTTPS, IMAPS, SMTPS. These are protocols handled by Camel and the underlying NSS library. In order to access the crypto token, we needed to supply a token PIN, which we were not able to pass from Evo to E-D-S in version 2.30 as "live" data (pass-and- forget). So we had to use a fake implementation: we store the user PIN along the rest of the account data and reading it in the backend via ESource. Clearly, this violates security (and we are saying to in our user manual), but it demonstrates that in principle, things are working. To get this thing right, we would need a means to ask for a security pin from within the backend, presenting a dialog to the user (not necessariy via Evo, maybe the new ESources and account management stuff Matt is working on could help with that). We've succeeded here _only_ since Camel uses the Mozilla NSS lib for securing connections. However, there is one protocol, for which we failed to implement any demonstrator for client-certificate-based authentication using a hardware crypto device: LDAPS. The implementation in Evo uses the OpenLDAP lib as a protocol implementation, which in turn uses GnuTLS for security (version 2.1x < 2.12 at that time). The combination of OpenLDAP and GnuTLS did not allow us to get things flying regarding the use of hardware crypto devices via the PKCS #11 interface. Where NSS only needs a token PIN and figures out either automatically or via external configuration files which of the possibly multiple client certificates to use, GnuTLS needs an URI which fully determines exactly which location inside the token to read the client certificate from, no automatisms here. While this allows for the application to control which cert to use (and not relying on any automatism, which may or may not work as needed), it requires the application to do it. Now, if on top of GnuTLS sits some protocol library like OpenLDAP, which rightfully denies to be bothered with security details of the underlying transport lib, we've got a problem: we must break the strict top-down layer approach and configure GnuTLS first, then use the protocol lib like OpenLDAP. We would have needed to hack around this directly in Evo to solve this, which clearly was (and probably is) out-of-scope for the evolution-kolab project. My question now is, how are the plans for Evo and E-D-S to handle these things, mid-term and long-term? Are there plans to favor any single one security lib, or will there be a multitude of different libs be used? GnuTLS is sort of home-made, while NSS is alien but works for the issue described above (which, admittedly, is a little esoteric, but *maybe* symptomatic?). In GnuTLS, I've seen much progress with PKCS #11 (like the integration of p11- kit), but it requires more details to be handled by the application itself. I'm looking forward to reading your input, Kind regards, Christian -- kernel concepts GbRTel: +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] Moving EExtension to libedataserver
Hi, I hope I've got the reference right... Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: > [...] > I'm going to need EExtension for the new D-Bus service I talked about > recently [1] anyway, so it makes sense to get this part merged early. Kind regards, Christian [1] http://mail.gnome.org/archives/evolution-hackers/2011-August/msg00025.html -- kernel concepts GbRTel: +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] Moving EExtension to libedataserver
Hi again, Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: > [...] > The API > is already fully documented and our wiki has usage instructions for it: > > http://live.gnome.org/Evolution/Extensions Is the list of EExtensible-tagged classes listed at the end of the wiki page up-to-date (and exhaustive) for the current dev version of Evo/E-D-S? I had a glance at the page since I'm trying to figure out whether or not the account setup stuff we're currently doing via EPlugin in evolution-kolab could instead be based on EExtensions (bearing in mind that EPlugin is going away sooner or later anyway). What's more, there are some Evolution UI extensions which we would like to implement for evolution-kolab, and since some of them are Kolab-specific, it seemed a better way to do it as an EExtension, rather than trying to hack Evolution directly. The questions at hand now are, do you see EExtension fit as an EPlugin replacement for account setup already, and can UI extensions (like additional entries in context menus or functional extensions of UI dialogs) already be done via EExtensions? Kind regards, Christian -- kernel concepts GbRTel: +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] Moving EExtension to libedataserver
Hi there, just one bit of nitpicking: Am Mittwoch 07 September 2011, um 19:07:20 schrieb Matthew Barnes: > [...] > The EExtension framework was introduced in Evolution 2.30 as part of the Shouldn't that read 2.32? At least, the wiki page says so. Kind regards, Christian -- kernel concepts GbRTel: +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] Moving EExtension to libedataserver
Hi all, Am Montag 12 September 2011, um 09:57:26 schrieb Milan Crha: > On Fri, 2011-09-09 at 22:18 -0400, Matthew Barnes wrote: > > I got this working today. Would anyone object if I create the > > gnome-3-2 branch early next week so I can commit this for 3.3.1 and > > then rebase my account-mgmt branch on it? > > Hi, > I wouldn't do that, as it doubles work for translators, because it's > their time now. Does it make that large difference to "wait" for next > two weeks? You can always do those things locally and branch&commit > later anyway. > Bye, > Milan Regarding the current plannings for porting evolution-kolab to a current dev version of Evo/E-D-S, it could prove very helpful to have this infrastructure available for basing our work on. We'd appreciate it much if the merge could be done as soon as the translator's window is closed and the merge can be done without foreseeable extra work for the release currently under preparation. Kind regards, Christian -- kernel concepts GbRTel: +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] towards Upstream-Integration
Hi, On Friday, 15 July 2011, Matthew Barnes wrote: > Sorry for the delayed response... NP at all, thanks for your input! > [...] > The process really isn't as formal as the wiki makes it out to be. > Because you're an extension module for an application that has already > met these requirements, and because you're using a compatible license, I > think for the most part you're grandfathered in. Sounds fine. Just wanted to make sure we don't miss something important. > > From there, I took the hop to http://live.gnome.org/CopyrightAssignment > > and found myself puzzled again. :) Of how much relevance are the details > > listed there for an Evolution plugin? Our source is LGPL v2.1+, the user > > docs and stuff are CC BY-SA ... so, are any details of that copyright > > stuff applicable to us? > > Obviously IANAL, but I believe as long as you're not engaged in such > nefarious activities as requiring outside evolution-kolab contributors > to hand over copyrights of their own code to you or your organization, > or are holding or seeking patents on parts of the evolution-kolab code, > there shouldn't be anything to worry about. Honest LGPL v2.1+, no tricks, no pitfalls. We're not evil(tm). ;-) > [...] > Translations will come when the project is added to Damned Lies > (http://l10n.gnome.org/). Long as the software is set up to receive > translations using gettext and intltool, which you said below it is, > you're fine. Yep. The gettext/intltool infrastructure needs some "love" still, but that should cause no harm. > > From there, the hop was to > > http://live.gnome.org/ReleasePlanning/ModuleProposing and the following > > questions arose: > > * does evolution-kolab as an Evo plugin need to go through the module > > proposal cycle? > [...] > > * "Judgement Criteria" ... can I deduce from what is listed there, that > > evolution-kolab > [...] > Again, because you're an extension module for an application that has > already passed this process, I think you're pretty much grandfathered > in. Maybe check with the release team about jhbuild, but otherwise I > see no need for evolution-kolab to undergo this process. Just start > uploading release tarballs when you're ready. Very well. jhbuild will be waiting for us somewhere farther down the road then. Thanks for the insights. We should be fine to continue from here. Kind regards, Christian PS.:I'll be on leave for a month, so I'll be able to continue with this topic only after returning from vacation and and being back inside my cubicle. Most likely, there will be some bugs and issues waiting for me to fix them, so I can just as well fix them first and push upstream next. -- kernel concepts GbRTel: +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] towards Upstream-Integration
Hi everyone, On Thursday 07 July 2011, Matthew Barnes wrote: > On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: > > The first step could be to create an evolution-kolab git repository at > > gnome.org, at least this is what came to my mind instantly. In order to get > > the prerequisites right, I have applied for a GNOME account with git > > access. > > This has been vouched for by the Evolution team (thanks, Matt), and I have > > received confirmation from the GNOME account management team today. > > > > Since neither my kernel concepts evolution-kolab team mates nor myself have > > done upstream integration for an Evolution plugin yet, I would like to know > > how we should best proceed from here. If there is any reading we should > > have > > done prior to further acting, we'll gladly accept pointers to the relevant > > documents. David (or anyone else involved there), I heard that you did the > > same with your EWS team recently, so if there are any lessons-learned which > > we > > should heed to, we will also be happy to know. Long story short, we will > > just > > be happy for any directing through this process so we can get through it > > smoothly. > > First of all, welcome to the family! It's great to have more developers > supporting new backends for Evolution. Thanks for the welcome. Reading through the available documentation and Matt's braindump, a few questions remained open, so I'll post them here (a) for my own education and (b) for the record: > I agree that getting the code into git.gnome.org is the first step. > Chen already pointed you in the right direction: > > http://live.gnome.org/Git/NewRepository ...this leads to http://live.gnome.org/ProjectPrerequisites where a list of prerequisites is presented. I think we do match all of these (see my follow-up to Chen's mail). However, it states there, that "To satisfy these requirements, particularly number 3, please send us any relevant URLs such as project homepage, list archives, ..." -- who is "we" in the case of evolution-kolab? The Evolution team? GNOME people? I'm not sure whom to contact for the paperwork. :) From there, I took the hop to http://live.gnome.org/CopyrightAssignment and found myself puzzled again. :) Of how much relevance are the details listed there for an Evolution plugin? Our source is LGPL v2.1+, the user docs and stuff are CC BY-SA ... so, are any details of that copyright stuff applicable to us? My traceback algorithm next pointed to http://live.gnome.org/ReleasePlanning/ModuleRequirements, where there is much about "modules", and the following (among other things) was not instantly clear to me: * Which will be the status for evolution-kolab? Will it be a "module" in the sense presented on the ModuleRequirements page? * We do have UI strings (in EPlugin), but no translation as yet - how about this? From there, the hop was to http://live.gnome.org/ReleasePlanning/ModuleProposing and the following questions arose: * does evolution-kolab as an Evo plugin need to go through the module proposal cycle? * (from here, loop back to ModuleRequirements and the question whether evolution-kolab is a "module" in that sense, if you like... :-) * is the email to the desktop-devel mailing list needed? * (from here, loop back to ProjectPrerequisites and the question whom to contact for the paperwork in case of evolution-kolab, if you like... :-) * 3.0 readiness: (void). We're 2.30(.3), porting to 3.x pending. How to deal with that? * Build testing: no jhbuild as yet -- only relevant once a new release from within the GNOME git is planned for? * "Judgement Criteria" ... can I deduce from what is listed there, that evolution-kolab is _not_ a module in the sense of ModuleRequirements? I frankly do not know what to make out of this stuff in evolution-kolab context... does this fall under the "don't care (yet)"-clauses? > When you're ready to start accepting bug reports, you'll also want to > get evolution-kolab added to bugzilla.gnome.org as a new project. The > steps for that are here: > > > http://live.gnome.org/Bugsquad/ForMaintainers#To_add_a_project_to_the_bugzilla_database Okay with that, should be fine. I guess I should mention the current (i.e. SourceForge) website in the bug report requesting a tracker for evolution-kolab? And is there a sensible way to migrate bugs from SF to bugzilla, or will we need to start anew? > Assuming evolution-kolab includes translatable strings, you'll want to > make sure the project is properly set up for localization using gettext > and intltool. This is kind of a broad topic, but there's lots of > documentation a
Re: [Evolution-hackers] [evolution-kolab] towards Upstream-Integration
Hi, On Thu 07 July 2011, Chenthill wrote: > On Fri, 2011-07-01 at 23:33 +0200, Christian Hilberg wrote: > > Since neither my kernel concepts evolution-kolab team mates nor myself > > have done upstream integration for an Evolution plugin yet, I would like > > to know how we should best proceed from here. If there is any reading we > > should have done prior to further acting, we'll gladly accept pointers > > to the relevant documents. David (or anyone else involved there), I > > heard that you did the same with your EWS team recently, so if there are > > any lessons-learned which we should heed to, we will also be happy to > > know. Long story short, we will just be happy for any directing through > > this process so we can get through it smoothly. > You could create a package naming eg: evolution-kolab and create a new > repository in git.gnome.org. http://live.gnome.org/Git/NewRepository > has all the details required. Let's see what http://live.gnome.org/ProjectPrerequisites says: 1. The project must be free/open source software. 2. It must use GTK+/GNOME technologies. 3. It must be maintained, and already have had at least one public release. 4. To the best of your knowledge, it must not infringe on patents (most gnome.org servers are in the US). 5. If copyright assignment is required, please first read our policy on copyright assignments; it's simpler to not have any copyright assignment. For evolution-kolab: 1. [ok] we're all LGPL 2. [ok] it is an Evo/EDS plugin 3. [ok] see http://evolution-kolab.sf.net/ 4. [ok] we're confident about that 5. [ok] should be no trouble, we're LGPL, no other copyright assignments apply I will thus proceed and create an evolution-kolab Git repo at gnome.org. Thanks, Christian -- kernel concepts GbRTel: +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-kolab] towards Upstream-Integration
Hi everyone. Since the last announcement of the evolution-kolab team here on the list, our source code (hosted at http://evolution-kolab.sourceforge.net/) has seen some more polishing and now compiles on Debian/Squeeze in addition to Ubuntu/Lucid. We will make available a (source) release 0.0.13 soon, which contains the fixes for Squeeze. Next week will see some performance improvements over the current state, and by the end of next week, I am planning to have the post-0.0.13 release ready. The code base has received quite some testing (under Ubuntu/Lucid) already, mainly in the area of Kolab inter-client compatibility. Online and offline operational modes are working, including conflict resolution. More testing is always welcome, of course. The evolution-kolab team now feels that we have reached a state where we can begin working towards upstream integration. During the planning and coding phases so far, we aligned all of our project decisions with the Evolution team as closely as our time schedule and resources permitted. This was done in order to promote for an easy upstream integration process. We would like to thank everyone here who helped us in the various aspects of creating a new Evolution plugin. We would very much like to be hosted at gnome.org with our project. SourceForge is a nice breeding platform, but we feel it is a little too far away from GNOME, and since we are a true GNOME project, we think it would be nice to add evolution-kolab directly to the Evolution project at its GNOME site. The first step could be to create an evolution-kolab git repository at gnome.org, at least this is what came to my mind instantly. In order to get the prerequisites right, I have applied for a GNOME account with git access. This has been vouched for by the Evolution team (thanks, Matt), and I have received confirmation from the GNOME account management team today. Since neither my kernel concepts evolution-kolab team mates nor myself have done upstream integration for an Evolution plugin yet, I would like to know how we should best proceed from here. If there is any reading we should have done prior to further acting, we'll gladly accept pointers to the relevant documents. David (or anyone else involved there), I heard that you did the same with your EWS team recently, so if there are any lessons-learned which we should heed to, we will also be happy to know. Long story short, we will just be happy for any directing through this process so we can get through it smoothly. Thanks a lot in advance, Kind regards, Christian -- kernel concepts GbRTel: +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-kolab] Vital signs from the project
Hi everyone. After a prolonged silence and a period of much work, the evolution-kolab team gladly announces what you could call a first release candidate of the Kolab plugin for Evolution (in fact, it is, only it has not officially been tagged as one). Source code, packages, user manual and some supplemental files can be found on the project's website, located at SourceForge: http://evolution-kolab.sourceforge.net/ We've made a more detailed announcement on the project's SF mailing list: https://sourceforge.net/mailarchive/message.php?msg_id=27679445 We're looking forward to receiving your feedback on the project, preferrably via the project mailing list or the project's bug tracker. Kind regards, Christian -- kernel concepts GbRTel: +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] Calendar PIM objects with inlined attachments
On Friday 08 April 2011 Milan Crha wrote: > [...] > With respect of "fetch on demand", it'll be tricky to achieve, to make > this done right on each operation which deals with the calendar > component in a certain way (operations like copy, move, send and so on). > But there is some API function, probably meant for something like that, > already, the e_cal_backend_get_attachment_list, used by > e_cal_get_attachments_for_comp. If at all we can support attachments in some way, and we want to be ready to work offline at any time, we'll have the actual data available as CamelMultipart message mime part anyways, so not much gain in trying the more complex "fetch on demand" ... as the attachments to Kolab PIM objects reside in the same email the actual PIM entry is in (as email attachments). I don't think 2.30 IMAPX can fetch just some mime part of an email and leave out another (is that even possible with IMAP?), and it is not dictated exactly which of the possibly multiple mime parts will be the Kolab XML file carrying the calendar data. To that end, we presumably cannot take any shortcuts or delay data fetch. (Bye)^2, Christian -- kernel concepts GbRTel: +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] Calendar PIM objects with inlined attachments
Hi everyone, thanks for the input so far. On Friday 08 April 2011 David Woodhouse wrote: > On Fri, 2011-04-08 at 10:35 +0200, Milan Crha wrote: > > On Fri, 2011-04-08 at 10:04 +0200, Christian Hilberg wrote: > > > We could use Evolution's file-link attachment mechanism by writing into > > > Evos file cache from the backend and placing the file paths into the > [...] > That's what we're doing in EWS, too. We store the attachments into the > backend's cache directory as obtained by e_cal_backend_get_cache_dir(), Just on a very short note: There's no e_cal_backend_get_cache_dir() in Evo2.30 (which is the one we're sitting on presently). That means we cannot maintain a backend-private file cache with this version, since we cannot inform Evo about it ... is that correct? (Bye)^2, Christian -- kernel concepts GbRTel: +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] Calendar PIM objects with inlined attachments
Hi everyone. While working on the evolution-kolab plugin, we found that there is no direct support in ECalComponent for attachments inlined into calendar objects. Thus, so far, we can cope with attachments inlined into Kolab calendar objects by hiding them in private ical fields. That way, we can preserve the attachment when writing back some calendar object to the Kolab server which has one attached. The drawback, however, is that we can access this (ical-private) attachment data via ECalComponent neither for reading nor for writing - it will just be invisible to the evolution-kolab plugin user, and they will get no indication that an object carries attachment data (they might just wonder why it takes much time retrieving and storing the object). We could use Evolution's file-link attachment mechanism by writing into Evos file cache from the backend and placing the file paths into the ECalComponent when reading calendar objects from the Kolab server, and read attachment file data from this same cache when creating a new object with attached files. We found a whole lot of issues with this approach (at least for Evo2.30), which I can detail if anyone is interested. Before trying anything with the at-least-problematic file cache approach, I thought I'll go ahead and see whether there is anything in the plannings regarding supporting inlined file attachments directly with ECalComponent in latest Evo versions. So far, I did not find anything related on the plannings pages. I'm not clear whether this has been discussed before or whether there are any current plans of extending ECalComponent to support inlined attachments directly (in which case a rather simple change to Evo would allow for supporing inlined attachments in a clean way). I'd like to know your opinions / ideas / ... on that matter. Greetings, Christian PS.:For those who followed the short discussion of the issue on #evolution yesterday, I thought it would be better to record the discussion on the list, so please feel free to paste your thoughts here again - just for the record :) -- kernel concepts GbRTel: +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] Backend requesting arbitrary user input from frontend
Hi Milan, On Wed 30 March 2011 Milan Crha wrote: > On Wed, 2011-03-23 at 19:04 +0100, Christian Hilberg wrote: > > Of course, this is going to be fun - how to tell which of the possibly > > multiple EDS-frontends should receive the request? Ideally, the backends > > should be unaware of EDS-frontends... trouble galore! :) > > Hi, > Matt suggested in his Account management that the server will ask for > credentials with an information for which "source" this request is made, > so the "auth_required" signal may contain this information. I'll add a > strv parameter to that, just for being ready even for more expansion. > > What kind of information will be known in this parameter depends on the > receiver for the signal. Let's have it opened for now, but I believe > this may cover your issue too. As long as there is *any* sensible way to pass some data (a PIN string in our case) to the backend if the backend so requests, that will help us much. Thanks in advance for taking this into account. (Bye)^2, Christian -- kernel concepts GbRTel: +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] Backend requesting arbitrary user input from frontend
Hi again, Am Mittwoch 23 März 2011, um 18:03:32 schrieb Christian Hilberg: > Hi all. > [...] > Maybe this is a more general thing than just having a backend requesting a > user PIN. I can imagine other scenarios where a backend might need to > request any user interaction, input, whatsoever, which is specific to this > backend and cannot be taken care of in the existing general EDS API (which > is limited to the typical things all backends need to do). > [...] Of course, this is going to be fun - how to tell which of the possibly multiple EDS-frontends should receive the request? Ideally, the backends should be unaware of EDS-frontends... trouble galore! :) (Bye)^2, Christian -- kernel concepts GbRTel: +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] Backend requesting arbitrary user input from frontend
Hi all. Part of the overall evolution-kolab project is to make it possible for Evolution (as a Kolab client) to use TPM [1] infrastructure. In short, it's all about certificate based client authentication, where clients can be forced to authenticate themselves against a server when establishing an SSL connection. It's the SSL server certificate based auth the other way around - first, the server will identify itself by sending a signed (and therefore, hopefully, trusted server certificate), then, the client will authenticate itself to the server by sending a signed client certificate. Only after the client sent a known, signed and trusted certificate, the server will ask for service authentication (username/password). If the client cannot authenticate, the server will terminate the SSL connection. Using a TPM means that the client certificate is stored within a hardware crypto token, the "Trusted Platform Module". To open and use the crypto token, the user needs to supply a user PIN (much like a password). Then only the crypto token will be accessible and will reveal the client certificate (or other data) it was asked for. Via the PKCS#11 stack (implemented through opencryptoki [2] and trousers [3]), it is possible to use this under Linux. It is working for Camel (via NSS) already. Given the proper setup, the Evolution frontend will pop up a PIN requester where the user can enter his/her crypto token PIN, and the crypto token reveals the client certificate to NSS for use in certificate-based client auth. This means that Camel can also use it. It works for us, there is a draft installation and setup guide available in the evolution-kolab project on SourceForge [4], namely Usage_of_software_security_devices_for_client_authentication.pdf (check out the "Files" section). We can secure e.g. an Evo IMAP connection that way. Now, we're using Camel (to be more specific: IMAPX) in our evolution-kolab backend, since all Kolab PIM data is stored in emails accessible via IMAP. We would like to use the TPM crypto device there as well, but we're lacking a possibility how we can request a user PIN from within the backend process through the frontend, since there is no API which would allow us to open a requester in the frontend (like, displaying some explanatory text, and having a field to enter some text, and an ok/cancel button, the entered text being handed back to the backend). This lack is there at least in 2.30, for which evolution-kolab is currently being developed (porting to newer versions is in the plannings, once we're done with the initial 2.30 release). Maybe this is a more general thing than just having a backend requesting a user PIN. I can imagine other scenarios where a backend might need to request any user interaction, input, whatsoever, which is specific to this backend and cannot be taken care of in the existing general EDS API (which is limited to the typical things all backends need to do). I'd like to know your thoughts on this, and maybe other backend implementors already had a similar need to request some user data which is not readily available through the standard EDS backend API. Kind regards, Christian [1] http://en.wikipedia.org/wiki/Trusted_Platform_Module [2] http://sourceforge.net/projects/opencryptoki/ [3] http://trousers.sourceforge.net/ [4] https://sourceforge.net/projects/evolution-kolab/ -- kernel concepts GbRTel: +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 2.28 obsolete?
Hi Matt, On Thu 27 January 2011 Matt Davey wrote: > I'm not sure this is the right list, as this is more of a policy > question than a dev question. > > I recently logged a bug (#639970) that crops up every now and again for > me, and it was closed as OBSOLETE because I raised it against Evolution > 2.28. This surprised me, because this 2.28 is the current shipping > version for Ubuntu 10.04 LTS (Long Term Support). > [...] For the unpleasant but real truth, see Pauls answer. As a quick workaround, however, if your own/company/whatever policy permits, you could try and install Evo 2.30.3 from the PPA https://launchpad.net/~jacob/+archive/evo230 and see whether it solves your problem. But be aware, that - Evo 2.30 is as obsolete as 2.28 is - while Jacob does a nice job providing Evo 2.30 for Ubuntu 10.04, this version is neither supported by Upstream, nor by Ubuntu, so no more fixes will go into currently provided 2.30.3, unless there would be a 2.30.4 release by the Evo maintainers (chances are as close to zero as you can imagine). Just 2 cent, Christian -- kernel concepts GbRTel: +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] Account management and keyrings
Hi, On Thu 20 January 2011 Matthew Barnes wrote: > On Thu, 2011-01-20 at 18:24 +0100, Milan Crha wrote: > > Nope, go for it. It may also fix an issue with Birthday&Anniversaries > > calendar, when using authenticated addressbook, as right now there is no > > easy way to ask for a stored password for that book. Of course, there > > will be needed new API for book/cal backends to be able to ask for any > > password (on any ESource), not only during its "authenticate" signals. > > Even it's another story, please consider these things too. > > Right, that was my intention with the new API. Backends could look up > passwords for themselves and only emit "auth-required" signals if they > need input from the user. ++ from the evolution-kolab team. Any idea on how to handle exactly this right now (we'll be implementing that soon on a totally obsolete Evo version, i.e. 2.30 ;-)? Since we did not yet implement this part, we can do so in a way which will avoid complications when porting to a recent Evo version later on. Greetings, Christian -- kernel concepts GbRTel: +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: public Git repo online
On Friday 17 September 2010 Christian Hilberg wrote: > [...] > There is a mailing list which should become acessible over the weekend. It's there now. (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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-kolab: public Git repo online
Hi everyone. JFYKI: There is a public Git repo online now with some sources for the evolution-kolab plugin. If you like, check out http://sourceforge.net/projects/evolution-kolab/ The repo is not open for public commits, though. Please be aware that this code is very much pre-alpha and not at all in any working state (though some parts are working already). Suggestions and other helpful comments are welcome. There is a mailing list which should become acessible over the weekend. This list will be: evolution-kolab-de...@lists.sourceforge.net Your mailing list info will be at: http://lists.sourceforge.net/mailman/listinfo/evolution-kolab-devel We'll be glad to meet you there. Best regards, and have a nice weekend, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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: on (Unit) testing again
Hi, On Friday 16 Juli 2010 Matthew Barnes wrote: > On Fri, 2010-07-16 at 15:54 +0200, Christian Hilberg wrote: > > Within our project it has been brought up that POSIX shell scripts might > > be a good choice in order to keep a low profile depencency-wise. > > Personally, I would prefer a higher-level scripting language which will > > offer more facility (esp. when it comes to mocking certain services or > > other complex things which will be a little bit painful to do in shell > > scripts). Nonetheless, I can perfectly understand the reasons if one > > prefers POSIX shell or something the like. > > I think Python would be the most palatable choice for GNOME software. > And you should be able to rig up a mock service pretty easily with the > libraries it provides. python has been accepted as the one single language for scripting within the evolution-kolab project, with an if-ever-needed-fallback, which is POSIX shell script (which we will try to avoid since python should be even more portable today than POSIX shell scripts are). Best regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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: Subclassing and extending IMAPX
Hi, On Thursday 09 September 2010 Christian Hilberg wrote: > [...] > ANNOTATEMORE and METADATA differ in the syntax they use and they have some > minor semantic differences. > [...] Just for your reference: "RFC5464 - The IMAP METADATA Extension" http://www.faqs.org/rfcs/rfc5464.html "IMAP ANNOTATEMORE Extension" (version 05 as implemented by Cyrus imapd) http://tools.ietf.org/html/draft-daboo-imap-annotatemore-05 So long, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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: Subclassing and extending IMAPX
Hi again, On Thursday 09 September 2010 Christian Hilberg wrote: > [...] > PS.: I will have to check with git-submodule whether we can track just > some part of the E-D-S git with that (i.e. IMAPX) ... if we can > track the full E-D-S git only, then I will have to think up something > else. Hum, neither submodule nore subtree merging seem to fit the purpose here, since in neither case I can refer to a certain part of a git repo but only to a complete one (would be evolution-data-server in this case, which does not make sense). New thought: Add a new branch to my project and include camel/providers/imapx sources there (a camel/ folder does exist anyway). Alas, in addition to the IMAPX headers, I need to duplicate the implementation files as well, since neither libcamel nor libcamel-provider do export IMAPX symbols (which is ok). I'm then able to #include as if I was part of evolution-data-server, and linking against the installed e-d-s (libs) works. In my own camel/ tree I will keep the extended functions for IMAPX ... not very pretty indeed but maybe good enough for now. In the event of a new upstream release, I copy the new upstream IMAPX sources to the camel-imapx-sources-branch and merge it over into my own development branches again. Should not be too much work, but would not be fully automated either. (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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-kolab: IMAPX licensing
Hello again.
While working through the IMAPX sources, I noticed that there are three kinds
of licenses in the headers for the *.[hc] files of the IMAPX implementation:
* GPLv2
* LGPLv2
* {nil}
The COPYING file in the E-D-S toplevel directory states LGPLv2, this is what
we checked initially.
Are the IMAPX file headers going to be fixed in near future regarding
licensing information? And if so, which will be the license they're going to
be placed under? This will have a major impact on licensing considerations for
our evolution-kolab plugin (which we planned to release under LGPLv2.1+).
Thanks in advance for any helpful information.
Best regards,
Christian
--
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +49-271-771091-19
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-kolab: Subclassing and extending IMAPX
Hi everyone. After some time working on different places within our Plugin, I'm back to our IMAPX part. We would like to use the IMAPX implementation for our backends as well as for the Evolution Email part when Kolab access is configured. Thing is, we cannot just use the plain IMAPX implementation since we need to support the IMAP ANNOTATEMORE draft to access Kolab's (i.e. Cyrus') folder annotations to tell the different folder types apart. Distinguishing between the different folder types is vital because it lets us know which entries the respective folders hold (Email, Contacts, TODOs, Calendar entries, ...). Depending on the folder type, each of our IMAP-Providers (Email in Evolution, Address and Calendar in the backends) will care for a given folder type or a set of folder types. When in Email context - i.e. within Evolution - our IMAPX derivative would not display Address folders or Calendar folders. The Address provider will only care for contact folder types, and the Calendar provider will take care of TODOs, notes, appointments etc. (in short: all Calendar data). Now, we have several issues here. Presently, this whole folder annotation stuff which is implemented in the Cyrus imapd (which is what the Kolab people use) is based on version 05(!) of the IMAP ANNOTATEMORE draft and it will stay this way for some time. The IMAP ANNOTATEMORE draft is what eventually turned into RFC5464 "The IMAP METADATA Extension", but RFC5464 is not what Cyrus currently implements. There are efforts to incorporate RFC5464 into a future release of Cyrus (its in the plannings for 2.4, current stable is 2.3). It will be quite a while, maybe years, before this will happen, and in the meantime we will be stuck with this early version of the ANNOTATEMORE draft. Up to version 07 of the draft, the old ANNOTATEMORE syntax and semantics are used and Cyrus advertises this in it's CAPABILITY response. This was changed afterwards and turned into METADATA before the final draft version 10 (the intermediate ANNOTATEMORE2 has never been implemented anywhere, AFAIK). ANNOTATEMORE and METADATA differ in the syntax they use and they have some minor semantic differences. Why am I writing this: IMAPX supports neither ANNOTATEMORE nor METADATA. My initial thought of patching IMAPX directly IMHO does not make too much sense presently because there is no imapd as yet which supports RFC5464 (true??) and ANNOTATEMORE is a draft and it's already been obsoleted by RFC5464 (so littering the IMAPX code with ANNOTATEMORE would not be too nice). This made me think whether we could extend IMAPX within our plugin and the ANNOTATEMORE (and METADATA) extensions could prove their ground there first, before finally being pulled upstream, if the Evolution maintainers would wish for that. Apart from the ANNOTATEMORE/METADATA extensions, which are upstream candidates, there are some Kolab-specific extensions, which most probably do not make sense upstream. These could be kept within the plugin code, even if the ANNOTATEMORE/METADATA should get pulled upstream and subsequently removed from our plugin code some day. The Kolab extensions include an API extension to IMAPX which enables us to configure a "context" into IMAPX. The "context" would be defined by the set of folder type a certain IMAPX instance should care for. By default, it would be "every folder but the known Kolab PIM folders". This default would be used within Evolution, so Evolution does not need to know about an extended API and use the provider as-is (it would then not present Kolab PIM folders to the Email frontend). From within our backend code, we could re-configure the respective provider instances via the extended API as to care for contact folders (EBookBackend) and for calendar data (ECalBackend) only. This way, we would still have multiple access to the IMAP server, but each mailbox would only be accessed by one IMAPX provider instance at a time (left alone the "delete mailbox" part, for which we will have to think up a good solution, still). The folder annotations can be retrieved without actually SELECTing a mailbox. Each provider instance would keep it's own cache, but would cache it's own folder types only. This way, there should not occure any duplicate caching. Does this sound "sound" to you? :-) IF it does, then the next question would be how to do that technically. From within our plugin code, we cannot directly access IMAPX headers, since (for good reason) they are not installed (and we would like to be able to link against installed Evo and E-D-S libs for user convenience). Still, I would like to avoid duplicating all of IMAPX within our plugin, but instead use the existing code wherever possible and just redefine the single functions which we need to extend or change. This would keep a patchset as small as possible while not really diverting from upstream. Due to time constraints we cannot currently car
Re: [Evolution-hackers] evolution-kolab: IMAPX RFC2086/RFC4314 (IMAP4 ACL) compliance
On Wednesday 25 August 2010 David Woodhouse wrote: > ∄ ACL support in imapx. Thanks for the information (though I was hoping for a different one :-). (Bye)^2, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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-kolab: IMAPX RFC2086/RFC4314 (IMAP4 ACL) compliance
Hi everyone, searching Evolution lists, docs and source, I found that supporting IMAP4 ACLs has been discussed now and then, but I could not deduce from what I've read that the IMAP/IMAPX providers actually do support ACLs. Support for IMAP ACLs would be very useful when dealing with a Kolab server (which uses Cyrus imapd with ACL support), so I'm interested in getting to know about the current status of ACL support within IMAPX. Kind regards, Christian -- kernel concepts GbRTel: +49-271-771091-14 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 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
