[Evolution-hackers] Evo and Kolab2 - a fresh attempt
Hi everyone. Presently, my company and it's associates are in the process of setting up an open source project to (among other things) integrate Evolution with the Kolab2 groupware server. The goal is to support as much of Evo's and Kolab's functionality as possible. We have searched the web for information on similar projects and so far found all of them in some kind of stasis or to be abandoned. In case we've overlooked something and there is active development going on somewhere in this regard, we'd be grateful to receive a pointer to the respective project(s). We aim to create a project which has good chances to go upstream. Plans are to implement an E-D-S backend for Evo like the one for GroupWise. At the moment I'm tasked with collecting information on how to do it the Evolution way in order to improve the project's chances to go upstream. QA is one of the topics which will be stressed, so I was checking how unit testing is done within Evolution. Skimming through the sources of Evo 2.28.3, I found that there does not seem to be the one specific way of doing testing, hence I would be interested in getting to know whether there is a preferred way of doing (unit) testing. Connecting Evo and Kolab2 will most likely involve rather heavy use of LibCamel infrastructure. Which Evolution version we will concentrate on is not yet fixed, but reading the mailing list archives I found there is a lot of change due to happen within this library. Although we might settle upon the current stable Evolution (or even the Evolution version of some specific stable Linux version, for a start), we would like to keep in mind that the Camel API will change and internals like the type system will undergo some major transitions. We would therefore like to avoid to writing code which will be hard to port to newer Evo versions. Unfortunately, there does not seem to be a new developer's guide which lists the pitfalls to avoid when writing backend code for current stable versions of Evo which should later be ported painlessly to newer versions of Evo. It would be great to be pointed into the right directions here. Questions galore - any helpful input will be kindly appreciated. :) Best regards, Christian Hilberg -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48Fax: +49-271-771091-19 D-57072 Siegen Mob: +49-176-21024535 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 and Kolab2 - a fresh attempt
Hi there, while the project setup process is going on, I've had a look again at suitable testframeworks. Unfortunately, many unit test frameworks for the C language appear to be abandoned. On Wednesday 26 May 2010 at 12:18:04 you wrote: Hi Christian, On Wed, 2010-05-26 at 11:15 +0200, Christian Hilberg wrote: We'll check that out with other Gnome projects. It may take some more research on the project itself before we know how to actually accomplish the testing stuff. My thoughts atm tend towards cunit/expect and/or the GLib testing framework. I think the consensus from 10k feet is something like: any unit tests are good ! wow, you have unit tests ? cool ! :-) so it is unlikely that anyone is going to come and gripe about your unit testing framework per-se; of course people moan about new dependencies - so re-using the gtestutils.[ch] would be good if it's easy, and of course most preferably hooking it all up to 'make check' is best, as Matthew said. Using the GLib framework for testing seemed to be a natural choice, until I dug through the mail archives and found that it (a) is neither nice to set up for projects outside GLib/GTK istelf [1] (latest information I found on the issue dates back from 2008) (b) nor is it well-documented and finally (c) does not seem to be in wide use outside GTK and GLib itself. Other testframeworks I've checked (like CUnit, cUnit, RCunit, CuTest, Embedded Unit) did not receive project updates since 2006 (some since 2003), so I assume they're dead. Setting aside commercial frameworks, which are no option unless they're explicitly FLOSSed, I'm left with Unity[2], Cutter[3] and Check[4]. Cutter depends on GLib = 2.16, so I assume it uses the GLib testing framework internally and I found references to it in some GTK/GLib context. What's more, Cutter has support for GLib types (just read in the docs, no practical experience as yet), which would be helpful in our case. Check seems to be in wider usage. It fork()s a new process for each unit test it runs, which seems to be a good thing to do to protect the framework's address space from runaway test cases, unless you're so much restricted (as in some embedded environments), that you cannot fork() - but there is no point in running E-D-S in such an environment, anyway. Unity (also) targets embedded contexts and the Sourceforge project is alive (latest release 2009-12-07, current checkins to the SF repo). There does not seem to be much of a documentation online. Long story short, as for now I'm down to either Cutter or Check to use. I'd like to know if you prefer one over the other, which I would like to take into account for my proposal to the other project members regarding the testframework to use. Best regards and aTdHvAaNnKcSe for any insights, Christian [1] http://www.mail-archive.com/gtk-devel-l...@gnome.org/msg07185.html [2] http://sourceforge.net/apps/trac/embunity/wiki [3] http://cutter.sourceforge.net/ [4] http://check.sourceforge.net/ -- 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] Datastructures for calendar data
Hi there, I'm trying to dig up the EDS data structure which is currently used to hold calendar data. Searching the sources (among others, evolution-mapi), I found ECalComponent being used as a toplevel data structure for calendar data. Regarding this data structure, I found: e-cal-component.[ch]: this contains ECalComponent, a GObject-based wrapper around libical's icalcomponent structure, although it does not offer all of its functionality (for instance, ECalComponent does not manage VCALENDAR objects). -- http://www.go-evolution.org/EDS_Architecture#Calendar We had some plans for using ECalComponent in all parts of Evolution/EDS hiding icalcomponent, am not sure whether we can still do it as ECal interface exposes icalcomponent in many places. It would be good to use ECalComponent as its object oriented and so would help us in avoiding copying icalcomponent structure at many places. ECalComponent would need more API’s for manipulating icalcomponent which is a reason why we use both of them. -- http://chenthill.wordpress.com/2008/08/ I'd like to know how you see ECalComponent's present (Evo2.30) status. Will it suffice for handling calendar stuff alone, or is icalcomponent still needed? We need this information for interface specification, and I'd like to avoid * crippling our interface by specifying a single data structure which does not cover all aspects needed for calendar data handling (is this the case for ECalComponent?) * using data structures which are in the process of being wrapped-up and hidden away in the near future (is this the case for icalcomponent?) aTdHvAaNnKcSe for any helpful information, 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 and sync- vs. async-Backends
Hi there, reading about the new IMAPX implementation used by Evo =2.30, I found it stated that Maybe if imapx had come up before, many backends such as groupwise, mapi etc. would have followed this design rather than a sync one. -- Chenthill in [1] Does this mean that the Camel IMAPX code is ready to support a backend like ours (for Kolab2) to be implemented as an async one rather than a sync one (which is the case for the MAPI-, Exchange- and SCALIX-Backends (and maybe others, too))? Best regards, Christian [1] http://chenthill.wordpress.com/2010/01/11/evolution-with-improved-imap-support-imapx/ -- 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] Evo-Plugin Coding Style
Hi all, searching evolution-hackers about Evolution coding style, I found http://projects.gnome.org/evolution/patch.shtml referenced as the coding style reference ;-) for Evolution. Is this document still fully valid so we may use it as style guide for our project? Are there any sections in this document which do no longer apply (e.g. Evolution moved to C99 or something the like)? Thanks for any input on the issue. Greetings, 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] Evo-Plugin Coding Style
On Thursday 01 Juli 2010 at 13:01:22 Matthew Barnes wrote: On Thu, 2010-07-01 at 11:43 +0200, Christian Hilberg wrote: searching evolution-hackers about Evolution coding style, I found http://projects.gnome.org/evolution/patch.shtml [...] That's still more or less valid. There's details there I would nitpick but if you're writing your own module you have more freedom to do it the way -you- want. I'll propose this as our style guide then. Just like Ross in one posting (I think back in 2009), I'm interested specially in getting to know about indent style. patch.shtml talks about 8-space-tabs (and true tabs instead of blanks). Since there are other Gnome projects (like Gimp) which do not allow tabs - but use blanks for all indentation, for purposes e.g. of alignment of parameters in multi-lined function signatures - I wanted to be sure here that we follow the proper Evolution-path. If in doubt, look at code samples from evolution/shell, as that's all been rewritten recently and follows our preferred coding style these days. Okay, thanks. 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] Evo-Plugin Coding Style
On Thursday 01 Juli 2010 at 13:30:26 Tor Lillqvist wrote: style. patch.shtml talks about 8-space-tabs Just some nitpicking here: I hate it when people say loosely that tabs correspond to 8 spaces (or four, or whatever). For good reason. :-) Just quoted http://projects.gnome.org/evolution/patch.shtml (Coding Style), which may not be too accurate about this...? A TAB character indents to the next multiple of the tab width. The tab width is a certain number of columns. Exactly how many spaces that then corresponds to obviously depends on what the current column before the tab is. Maybe the Evolution Patch Guidelines could use a little updating, if there is enough consent about how to deal with the nitpickable parts. Greetings, 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] Evo and Kolab2 - a fresh attempt
Hi Michael, On Wednesday 26 May 2010 at 12:18:04 Michael Meeks wrote: Hi Christian, [...] It'd be better really to develop vs. master - from a support, testing, future-proofing, and ease-of-use perspective. Presumably it is possible to get you commit access to the repository so you can develop in the repository [ when some code has been reviewed ] - it sucks to be stuck out on a limb somewhere. We'd surely like to commit to the Evo repo. We're in the plannings still, but it is a request from our customer that our results be made public under GPLv2, and if possible, be accessible via the upstream project repo. We have some skeleton code which mainly serves to explore the wonders of Evolution right now and which we will turn into production code at some point. We will be working on the code with - as per present plans - five active developers. We're using our own Git repo for now, but it would be good for us to know that you people are willing to host us later on (that is to satisfy our funder's requirement). We'll develop our Plugin in a way that it will be a standalone one, just the way evolution-mapi is. Presumably, we will name it evolution-kolab. Shouldn't be too hard to transfer our own Git repo to your site. Is that okay with you? Anyhow - exciting to see this get underway; hopefully it can also be used as part of the Windows build - as a neat extra :-) We'll try to be as portable as possible, but our main target is Linux for now. Using GLib and friends wherever possible should prevent us from being totally Linux-specific, though. :-) Best regards, Christian PS: @Michael: sorry for the double posting, this should have gone to the list right away. -- 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: Lifting the veil
Hi all, I think it is time to provide the list with some details about us and our project. I will give just a short overview here. If you'd like to know more details, please feel free to ask. About us The main developers for the evolution-kolab project are employees of two German conmanies. The companies are kernel concepts [1] tarent Ltd. [2] Both companies are active in the Linux and OSS development field. See the respective websites for more info (english versions available). The Developers are Nils Faerber(kernel concepts) Silvan Fin (kernel concepts) Christian Hilberg (kernel concepts) Hendrik Helwich (tarent) Umer Kayani (tarent) More resources may be allocated as needed. :) About the project The goal of the evolution-kolab project is to provide a plugin for Evo/EDS which will allow Evo users to utilize a Kolab 2 server [3] as a groupware solution. We will try to map as much of Kolab's functionality as possible onto Evolution whithout changing Evolution itself (other than providing a plugin, that is). Especially, we will not touch core Evolution or E-D-S. The fun thing about Kolab is that our backends will need to talk not only IMAP and SMTP (for retrieval/storing of contact data and calendar data), but also LDAP (another contact data source) as well as HTTP (trigger for free-busy-list generation and f/b-list data retrieval). Some tech details have already been discussed on evolution-hackers. It is required that all data transport be secured via SSL/TLS if at all possible (as an option for the user). We will need to provide working and tested results by the end of Q1/2011, latest. This means we have a tight schedule, so we have to restrict ourselves on a number of issues. These are (including, but not limited to ;-): * targeting Linux for client and server *solely*. No specific attempts will be made to be portable to other platforms (like *BSD, Windows, ...). Nevertheless, by offloading as many low-level-details as possible to GLib and friends (and making use of highlevel Evo/EDS infrastructure), it should be possible to port to other platforms fairly painlessly. * targeting Evo/EDS 2.30 only (2.30.2 presently, we should be able to follow patchlevels). It is a customer requirement that the plugin be used with current stable versions of GNOME and we will not be able to stand API churns or move to GTK+-3 on our development platforms for several reasons, mostly due to development deadlines. However, we will actively read evolution-hackers for updates on the upcoming changes in 2.31 and try our very best that our code be portable to 2.31 with as little pain as possible. * targeting Kolab 2 (either Version 2.2.3 or 2.2.4, this has to be discussed internally, still). Kolab 1 will not be supported. * providing DEB packages for Debian/GNU Linux only. RPM packages should not be too hard to generate from our debs (or by other means), but we will not be able to provide them. * User manuals and other documentation will be in German (another customer requirement). Volunteers who will translate to English and other langs are welcome. Source docs will be in English, of course. Testing will be done using the GLib Testing framework for unit tests. As far as integration testing goes, we're not yet settled but I think we may use python, expect or something the like for automation. Coding style will follow Evolutions conventions [4] as closely as possible. Our project will be GPLv2 (or a comparable FLOSS license which will assure at least GPLv2's freedom level ;-). There should not be any licensing issues here. If there are doubts, please feel free to ask for clarification. Our customer, for whom we will develop this solution, is also very specific about the project being hosted publicly and accessible by everyone. If Evolution staff will be willing to host our project sources within Evo git repo, we'll happily transfer our stuff there as soon as we have a first preview ready. So long for now, Best regards, Christian [1] http://www.kernelconcepts.de/ [2] http://www.tarent.de/ [3] http://www.kolab.org/ [4] http://projects.gnome.org/evolution/patch.shtml -- 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: local cache for offline-work
Hi all, in evolution-kolab, we need to provide full offline capabilities for working with Kolab 2 groupware data in offline mode. Evo 2.30 has an offline mode which works for IMAP email. If I understood correctly, email handling resides within Evolution presently [1], not E-D-S. For our plugin, though, we need to place email stuff in the backend (for handling contact data and calendar data, as these are stored in XML attachments to emails within Kolab 2 context). This means we will need to sync emails (with proper conflict resolution) when re-connecting to the Kolab server which hold calendar data and contact data. What's more, we have a multimaster-situation here. As Matthew already pointed out in [2], this is sort of new terrain we're stepping on. In order to get an idea about how much work it will be to implement this feature, I'd like to know whether there are ideas already concerning caching calendar data and address data this way. Alas, I have not found time yet to dig into existing backends to check whether they do caching already or whether there is any infrastructure provided with Evo/EDS 2.30 which we could use for that matter. We'll be happy to receive any pointers into existing plugins where something like this is already done or to discussions about the issue. Thanks in advance, Christian [1] http://mail.gnome.org/archives/evolution-hackers/2010-June/msg00018.html [2] http://mail.gnome.org/archives/evolution-hackers/2010-June/msg00022.html -- 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: Lifting the veil
Hi Michael, On Thursday 08 Juli 2010 at 17:01:36 Michael Meeks wrote: [...] On Thu, 2010-07-08 at 10:28 +0200, Christian Hilberg wrote: We will try to map as much of Kolab's functionality as possible onto Evolution whithout changing Evolution itself (other than providing a plugin, that is). Especially, we will not touch core Evolution or E-D-S. It would be good to know what we are missing though - if there are new and interesting things that can be added to the front-end. As we stumble across these things, we will let you know. :-) Right now, there is a Journal type in Kolab (which is what the Kolab reference client Kontact supports) which does not seem to have an equivalent in Evolution. There is the Memo type in Evolution (which seems to be held in an ECalComponent in E-D-S side - unsure about this, still), but the Memo does not seem to fully map with the Kolab/Kontact Journal type. But I may err here, corrections welcome (generally, that is :). [...] Our project will be GPLv2 (or a comparable FLOSS license which will assure at least GPLv2's freedom level ;-). There should not be any licensing issues here. If there are doubts, please feel free to ask for clarification. Soo - personally, I would love to see the code live inside e-d-s and/or Evolution itself: that should make it easier to maintain longer term, adapt for re-factoring, get translators involved etc. I'd like to refer you to http://mail.gnome.org/archives/evolution-hackers/2010-May/msg3.html where a different point of view is presented: We prefer backends for groupware servers to be packaged as a standalone extension module for Evolution. See for example evolution-exchange and evolution-mapi (and I believe the GroupWise backends will soon be split off similarly) -- Matthew Barnes We assumed that this is an authorative answer especially since there was no veto. :) But maybe I see a contradiction here where none exists. Licensing wise, the e-d-s code is currently LGPLv2, and Evolution is LGPLv2 or v3 (at your choice). I would recommend sticking with that, or going LGPLv2+, rather than having a plain GPLv2. Good point. I see no reason for not using LGPL. We will bring this to our customer's attention since it is their decision (if only for formalities' sake). General policy is to follow upstream project's licensing model. [...] If Evolution staff will be willing to host our project sources within Evo git repo, we'll happily transfer our stuff there as soon as we have a first preview ready. Perhaps something to dicuss on #evolution (irc.gimp.net) - but it'd be great to have you working in the same git repo IMHO [ not that it's my decision of course - I defer to Matthew/Chen etc. ;-] We'll be around for discussion. So far, all I can see is condition green. ;-) Thanks for the input, exciting times ahead. Best regards, Christian PS.:This went to Michael only, once again. I'm just not (yet) used to checking the TO: address when replying to a list posting since I implicitly assume the posting I answer to will have the list set as REPLY-TO: ... sorry for the delay -- 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: local cache for offline-work
On Thursday 08 July 2010 at 15:50:19 Christian Hilberg wrote: Hi all, in evolution-kolab, we need to provide full offline capabilities for working with Kolab 2 groupware data in offline mode. Anything? Anyone? :-) 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: local cache for offline-work
On Friday 09 July 2010 at 18:01:53 chen wrote: [...] Let me try to summarize some pointers for calendar and you could do the same for address-book as well, + Create New ECalBackend for Kolab + Use the camel apis to fetch the calendar folder + Using the CamelFolder, get its contents. You would mime data and you can use the Camel libraries again to parse these contents. + Convert the Xml calendar data into Ics format and store it into the backend Yeah, this much is clear. There will be a fully-fledged two-way lossless conversion between EDS data types and Kolab2 data types, and the conversion will most probably be done on-the-fly (if we run into performance issues here, we might change plans... :). So this helps for displaying the contents. Now with creating meetings/appointments. iirc you would need to send them via smtp ? + use the camel_transport apis (look through e_cal_backend_save/send api's) Also no worries so far. Let me be a little more specific (I should have been right away, but my mails tend to become lengthy...): * We need to create a local cache for emails which is handled by the plugin backend(s). * Does there exist any infrastructure in E-D-S which will help us creating a local email cache via IMAP? * Orelse, is there a sensible way to re-use existing caching functionality inside our backend which comes from Evolution, since Email handling resides there, presently? Without weaving knots between Evo and E-D-S which will be prone to failure and unclean, I mean? There are many backend implementations already available file, exchange, groupwise etc. and you can refer them.. I would recommend looking through groupwise/exchange and shoot your questions if any.. I'm in the process of having a closer look at them... Since no one has yet tried using camel apis, we do not know if there are any issues while you might face. But we should be able to help you while you progress.. Okay, thanks. Once I'M really clear that we have to do these things fully on our own and we cannot re-use existing infrastructure, I will instantly stop harassing you with this issue and start working. :-) I just want to avoid reinventing the wheel. 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: local cache for offline-work
Hi Chen, thank you very much for taking time to clarify things! Much appreciated. On Friday 09 July 2010 at 18:43:32 chen wrote: On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote: * Does there exist any infrastructure in E-D-S which will help us creating a local email cache via IMAP? Yes its available. CamelFolderSummary stores all the basic contents of an email which needs to be displayed in the MessageList view (label, subject, dates, fromto headers etc.). CamelDataCache stores the contents of the email (entire mime message) into the cache. The imapx provider would use them to store the mail data into cache. Okay, this helps. I think I saw these parts of Camel before, but I was not sure whether the facility provided would be sufficient for our needs. Seems we have what we need here. * Orelse, is there a sensible way to re-use existing caching functionality inside our backend which comes from Evolution, since Email handling resides there, presently? Without weaving knots between Evo and E-D-S which will be prone to failure and unclean, I mean? Current imapx provider implementation is in such a way that, once you access a message using camel_folder_get_message, the message would be completely downloaded into the cache and would be available for offline usage. camel_folder_refresh_info would fetch the summary contents and optionally fetch the message contents also if the folder is marked for offline usage (when the camel url property, 'sync_offline' is set). Again, this is valuable information. If I read this correctly, the IMAPX implementation would handle all caching so we would be left with only the actual synchronization problem. BTW, is there a way to intercept Camel's synchronization with the IMAP server after reconnecting (i.e., after leaving offline mode)? This question is because the PIM emails hold semantics to which Camel will be agnostic (since it thinks it only handles emails), and it could be problematic to cope with PIM sync conflicts if Camel will just sync the emails right away without a possiblitiy for us to hook-in an awful lot of extra sync logic. And i guess you would be re-using the existing imapx backend from evolution ? By all means! :-) Once you convert the xml data to Ical or VCard, you can make them available for offline usage based on ESource property, 'offline-sync'. Well well, this all sounds promising. [...] Once I'M really clear that we have to do these things fully on our own and we cannot re-use existing infrastructure, I will instantly stop harassing you with this issue and start working. :-) I just want to avoid reinventing the wheel. Oh np :) You can shoot your queries anytime.. Btw to be more clear no one has tried using camel apis from calendar+address-book backends. I think Matthew already mentioned this. But we will give it a try - not many options for us to choose from. :-) It might be a good idea to use separate instances of Camel providers for contacts and calendar data. We'll see. Thanks for all the fish :-) 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] Datastructures for calendar data
Hi again, no ideas? Anything? 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] Heads Up: More Camel API breakage in 2.31
Hi, On Thursday 08 July 2010 Matthew Barnes wrote: I finally finished converting Camel's error handling code to GError. CamelException is no more. Is there a sensible way how we could deal with CamelException in our evolution-kolab plugin, which will be developed against 2.30? This is, can CamelException be wrapped in a way which will ease up the transition to GError, once our plugin will be ported to 2.31? 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] Heads Up: More Camel API breakage in 2.31
On Tuesday 13 July 2010 Matthew Barnes wrote: On Tue, 2010-07-13 at 18:50 +0200, Christian Hilberg wrote: Is there a sensible way how we could deal with CamelException in our evolution-kolab plugin, which will be developed against 2.30? This is, can CamelException be wrapped in a way which will ease up the transition to GError, once our plugin will be ported to 2.31? There are a few habits to follow with CamelException which will ease the transition to GError: [...] Thanks, note taken. We'll try to catch you on every similar move. :) Greetings, 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] Datastructures for calendar data
Hi there, On Wednesday 14 July 2010 Ross Burton wrote: On Wed, 2010-07-14 at 20:14 +0530, chen wrote: Though only subclass this if you can't handle the async nature of the ECalBackend API yourself. Whether you subclass ECalBackend or ECalBackenSync is a choice made by how the backend will be implemented. Is this used by any backends or will be used ? I was just having this question while reading through the go-evolution.org link. ECalBackendSYnc adds the notification to the clients for the sync calls made by the clients through libecal, which anyways cant be ignored isn it ? So usage of ECalBackend functions for sync calls such as, e_cal_backend_create_object, get_object, get_object_list etc. just adds extra work of notifying the clients using e_data_cal_notify*. If the answer is, they are not used, better to mark them as deprecated and cleanup this area. ECalBackend can then just be used for Async apis like, e_cal_backend_notify_object_(added, modified, removed) and future free/busy async apis etc. But if your backend can make async calls (say you implement it using GIO) then you can drop the BackendSync layer and notify yourself. One of my plans was to move the each operation in a thread logic into E*BackendSync because asynchronous backends obviously don't need to be in a thread. Thanks for all input. This week, we should finish our initial planning phase and start implementing a few things. We'll have more time then to read code than it was the case before. I hope we'll have some spare time to organize all information into one document so it can serve as a reference. Most likely, it will be a copypaste-thing gathering the answers we got here. I'll post a link once we have something ready. 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: on (Unit) testing again
Hi all, regarding Unit-testing our plugin, we've settled on the GLib Testing framework and Unit tests written in C. Now, when doing integration testing, we will certainly try to automate a few things. Question is: does there exist a preferred scripting tool / language within the Evolution community for doing integration testing? I assume there is no preference so far, but maybe there are some thoughts about which route the Evolution project would like to take in future. 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. This is not meant to start holy wars. Still, I'd be interested in opinions (specially from the elders here :) about the topic so we can make a good decision. Many greetings, 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: Display of extended free-busy lists
Hi all, within the evolution-kolab plugin, we would like to display extended free-busy information if some is available on the Kolab server. Extended f/b lists have some text attached to the busy information for any user within the same calendaring group. This feature is provided by the Kolab server and we would like to make it available to the plugin users. Now, I'd like to know whether there is any sensible way in Evolution 2.30 to display this extended information in the free-busy-view. So far, I haven't seen something like this, but maybe I've missed it. Maybe some tooltip would do the trick, if one hovered the mouse pointer over a busy time of some attendee in the new meeting dialog. If something like this is not yet implemented, can it be done from within the EPlugin (without duplicating existing infrastructure)? I guess not, but again, I might have missed something. 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: using a TPM for SSL/TLS client certs
Hi all, ...the story continues... As a part of our project, we need to support TPM hardware as certificate source for client-authentication against client-auth-enabled services. Within Kolab context, these are mainly IMAPS, SMTPS, LDAPS and HTTPS. The tpm-tools suite and openCryptoki will serve as software layer between the TPM hardware and the NSS lib, talking to each other via the PKCS#11 protocol. We have validated already that the NSS lib can make use of certificates stored in the TPM via openCryptoki. In Evolution and E-D-S, I have seen references to PKCS#11 in S/Mime context only, so I assume there is no infrastructure for SSL/TLS client auth via NSS/PKCS#11 as yet. Is this correct? As far as the Camel lib goes, we have the situation that we will need to handle at least two instances. One in Evolution (which is there anyway) and at least one in the backends (E-D-S). As far as the EDS part goes, we would be able to configure NSS to use the TPM stack from within our plugin code. But foe Evo, I doubt it will be possible to do the same configuration from within the EPlugin, right? This would mean we needed to touch Evo code itself. Has anyone had any thoughts about this already? As for implementation, we thought it might be a good idea to implement the TPM stuff separately from the Kolab plugin. This would mean to leave Camel alone and to integrate TPM usage with the NSS lib directly. Do you think this would be an appropriate approach? Have there been any efforts before to do something like this? Questions galore, any input welcome. :-) 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: hiding IMAP folders
Hi all, ...still continuing... Kolab makes use of RFC5464 - The IMAP METADATA Extension IMAP folder annotations to differentiate between the various folder types which are handled by Kolab. Remember, anything (Email and PIM data) is stored as Email messages with XML attachments in IMAP folders within the Kolab context. This means, we have IMAP folders for Email, Calendars, Contacts, TODOs, Tasks and the like. Now, when creating a Kolab account, all of these folder types are generated on the server. There is at least one folder for each type, which is the default folder initially. From within Evolution, *only* the IMAP folder which is annotated Email should be visible and all others should be hidden, as their respective contents will be managed by the backends, not Evolution. Otherwise, users will be able to meddle with PIM data folders, which might result in disastrous situations on the server side. Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? Many greetings, 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: hiding IMAP folders
On tuesday 20 July 2010 Christian Hilberg wrote: [...] From within Evolution, *only* the IMAP folder which is annotated Email ^^ the IMAP folders which are annotated, this is. 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: hiding IMAP folders
Hi there, thanks Milan for your reply. On Tuesday 20 Juli 2010 Milan Crha wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? Hi, you said you want to use imapx internally, is it right? And even if IMAPX-only, yes. That's the master plan. :-) only the imap provider itself, then I would suggest to subclass it (your base imap provider) in your evolution-kolab package and manage this within CamelStore::get_folder_info, by calling parent class' get_folder_info and then recreate folder information based on your needs (once with email folders only, once with calendar folders only, and so on). Hm. Maybe I'm still missing some parts here on how Evolution internally works. Subclassing the Camel Provider in our backends and overloading get_folder_info() will work for the backend part, i.e. PIM data wich is accessed and managed from inside E-D-S. So far, no problem. But there is standard Email to handle as well, and if I understood correctly, Email handling is (presently) done inside Evolution, not E-D-S. Now, if I create a Kolab account, I will see not only the Email IMAP folders in Evolution (frontend, Email view), but *also* the parts of the IMAP tree for the Kolab server which hold PIM data. These are simply IMAP folders, just that they bear folder annotations. Other than that, the folders which hold PIM data (as single emails with XML attachments) are no different from true Email folders. This means, when I configure Evolution (2.30 let's say, without any Kolab plugin) as to access a Kolab server, nothing hinders Evolution to display the whole IMAP tree and the folders which hold PIM data just become visible as standard Email folders. This I cannot intercept from my backend code (or can I?), since Evolution just accesses the Kolab IMAP server without knowing that certain IMAP folders do not hold standard Emails which must not be accessible to the user. What's more, the IMAP folder layout in Kolab may change over time, as I create new address books, nesting things etc, so the folder tree is not static. Therefore, I cannot just pre-configure which folders to show and which ones to hide, I'll have to do this dynamically, solely relying on the folder annotations telling me which kind of IMAP folder I'm facing. For this to work, I would have to subclass the Camel Provider within my EPlugin - is that possible? So far, I have only seen EPlugins using existing Evolution infrastructure, but not changing the Camel Provider inside Evo... Hope that helps, Partly, yes. :-) Please feel free to correct me on any misconception I have regarding the internals of Evo/E-D-S, I'll be grateful for that. Also, if I need to be clearer on any Kolab issue, please let me know as well. Milan 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: hiding IMAP folders
Hi there, On Tuesday 20 July 2010 chen wrote: On Tue, 2010-07-20 at 12:20 +0200, Christian Hilberg wrote: [...] Is it possible to define certain IMAP folders as hidden from within our plugin's EPlugin part? Or is it possible to hide certain IMAP folders (and their subfolders) in any other sensible way? This cannot be done in a fool-proof way for IMAP as it does not provide information on the type of the folder. This can be done with an assumption that calendar folder will be named as 'calendar' or contact folders as 'contacts'. Not entirely correct, though. RFC 5464 - The IMAP METADATA Extension / imap- annotatemore specifies an extension to the IMAP protocol which does exactly that. The Kolab IMAP daemon uses this extension to differentiate between the folder types and Kontact does implement it - works quite well. Now, with our plugin, we strive to be en par with Kontact's features (or at least implement as much as possible) - let's see! :-) The other thought I get is, the contacts+calendar folder names can be collected as an option in account-setup and set as part of camel url (prolly through a kolab plugin, hiding it from the user. you can check how groupwise account set-up is implemented for an example) say hide_folders=list of folders with a separator. If the parameter is set, the folders can be hidden while fetching folder_info through camel_store_get_folder_info (in imapx backend), which gives the folder tree. Good idea. We'll have to check how to handle dynamic changes in the IMAP folder structure, still. Folders with annotations may come and go, nested or not - this is not static, and neither is the overall layout (other than a few static constraints), so we'll need to see how we can cope with that... We could add another flag in CamelStore to over-ride the above option to fetch all folders while fetching the folders from contacts(EBookBackend)/calendar(ECalBackend) backends. I can help you with making these changes in imapx backend/CamelStore and inform you the changes which you would need to make in your account-setup plugin. Sounds ok? We'll thankfully use whatever help we can get here. We also see clearly which problems arise in these areas because of our decision to settle on 2.30 ... this is the version we would need to change (branch is fine). It will be very much helpful to know which parts will be affected and how we should design our changes in order not to break anything. Thanks again for your help and for your awesome patience with us (this goes to the entire list). 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: Some design thoughts on Email handling
Hi Milan, thanks for your explanations, though they undermine what little idea about Evolution design I thought I had... ;-) On Friday 23 July 2010 Milan Crha wrote: On Fri, 2010-07-23 at 10:43 +0200, Christian Hilberg wrote: We would need the possibility to define extra D-Bus communication between Evo and E-D-S for that, right? [...] What I thought you'll do the easiest way was to define your own camel, subclass of imap/imapx, and add some property of source-type to it, which will lead folder showing on all of them. This camel part will be compiled first, because you will need it in book/cal backends. Note you'll have three simultaneous connections to your server, from three different processes. I must admit that I am not yet familiar with the communications structure between Evo and E-D-S processes. If we let one Camel Provider live in Evolution, then we need to access it's data from the address book and calendar backend (or the data has to be pushed to the backends), which will be complicated at best or may not work at all (corrections always welcome!). If we have three instances of our IMAPX subclassed Camel provider, then each instance needs to know which process it lives in (Evo for Email-only, calendar backend process, address book backend process). If each Camel Provider instance knows where it lives, it can then deduce which folder types it may access and present only those to the surrounding process. That way, we would have concurrent accesses to the IMAP server but at least we'd not be accessing the same data concurrently (other than the folder lists, which should be accessed read-only in most cases anyway). This might work, but I do not feel fully well with this solution... especially when it comes to nested IMAP folders which may be of different types (I'll have to check again whether Kolab allows such). I do not think moving mailer part to eds would help you much, the time where there was only one evolution-data-server-X.YZ process is gone :) Evolution exchange had been also running as a separate process, independently from evo and factories, some time back, which is very similar to your proxy, but it wasn't working well, so it was also rewritten in time of 2.29 (I think). Anyway, it is possible this way too; you'll get less connections to your Kolab server, if nothing else. Okay, I'll have to re-think this design then. I may have funny ideas at times, and some of them even work, but one would not have rewritten a plugin if the independently running stuff would have been a good road to take. :) Happy hacking, 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] Camel IMAPX RFC5464 compliance
Hi again. On Monday 26 July 2010 Christian Hilberg wrote: while I suspect the answer will most likely be no, just to be sure I'd like to put the question here anyway (if only for the record): Does the Camel IMAPX implementation comply with RFC5464 The IMAP METADATA Extension [1] ? [...] [1] http://www.faqs.org/rfcs/rfc5464.html After taking a closer look at the IMAPX implementation (and since there was no veto here), it seems clear that the 2.30 IMAPX does not support the RFC5464 IMAP protocol extension. Now, we need this functionality in our evolution-kolab plugin to avoid ugly workarounds (like scanning all folder contents in order to find out the folder type) when working with Kolab IMAP (PIM) Folders. We could patch the IMAPX implementation to add RFC5464 functionality. This would mean that IMAPX needed to be extended by two new IMAP commands (SETMETADATA and GETMETADATA), and one new response (METADATA). The GETMETADATA command has two options, MAXSIZE and DEPTH. The METADATA response may carry values. For further details, please see RFC5464. In all, it does not seem to be overly complicated. However, apart from implementing the protocol extension itself, it would mean to also extend the IMAPX API. This should be possible to implement just as an extension to the existing API so we would not break anything, right? Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? As an alternative, would anyone like to implement RFC5464 in the current upstream IMAPX so we could try and backport the changes into 2.30? 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: Camel.HttpStream in the wild (?)
Hi Matthew, thanks for the prompt reply. On Wednesday, 04 August 2010 Matthew Barnes wrote: On Wed, 2010-08-04 at 12:50 +0200, Christian Hilberg wrote: Using the Camel.HttpStream should do the trick - is that correct? I've seen the Camel.HttpStream being used within Anjal (file em-format-mail.c). Is this Camel HTTP part being used somewhere else as well (to be used as another reference)? You would be much better off using libsoup. Does libsoup make use of NSS (just the newbie's uninitiated question)? Camel.HttpStream is only used to retrieve remote images and such for HTML mail. I plan to kill that class as soon as we move to WebKit/GTK+ for HTML rendering. Hey, thanks for that hint! :-) Maybe it would be wise to mark such classes as deprecated/removal candidate or something in the docs. (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
Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)
Hi there, On Wednesday 04 August 2010 Matthew Barnes wrote: On Wed, 2010-08-04 at 13:28 +0200, Christian Hilberg wrote: Does libsoup make use of NSS (just the newbie's uninitiated question)? It uses GnuTLS for transport layer security. http://www.gnu.org/software/gnutls/ Is there any good alternative to using libsoup which makes use of NSS? We're pretty much depending on the (mostly) working NSS infrastructure for PKCS #11 and token handling for certificate based client auth. From what I've read I get the impression that GnuTLS' PKCS #11 implementation is still rather experimental (true?), so we would (a) step on even more brittle ground (b) have another lib which we potentially need to configure for cert token use (which, when incompatible with parallel NSS use, probably is a no-go) when implementing/configuring token access for client cert retrieval. Any hints on how to handle this situation? 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: Camel.HttpStream in the wild (?)
Hi Matthew, On Wednesday, 04 August 2010, Matthew Barnes wrote: On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote: Is there any good alternative to using libsoup which makes use of NSS? We're pretty much depending on the (mostly) working NSS infrastructure for PKCS #11 and token handling for certificate based client auth. That I don't know. You might want to ask the libsoup maintainer, Dan Winship (d...@gnome.org). [x] done. I've posted to the libsoup list, see [1]. Maybe we can dig up something useful there. Thanks and best regards, Christian [1] http://mail.gnome.org/archives/libsoup-list/2010-August/msg0.html -- 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: Camel.HttpStream in the wild (?)
Hi again, On Wednesday 04 August 2010 Christian Hilberg wrote: On Wednesday, 04 August 2010, Matthew Barnes wrote: On Wed, 2010-08-04 at 16:03 +0200, Christian Hilberg wrote: Is there any good alternative to using libsoup which makes use of NSS? We're pretty much depending on the (mostly) working NSS infrastructure for PKCS #11 and token handling for certificate based client auth. That I don't know. You might want to ask the libsoup maintainer, Dan Winship (d...@gnome.org). [x] done. I've posted to the libsoup list, see [1]. Maybe we can dig up something useful there. Result: While libsoup should build against the current GnuTLS lib (development version, 2.11.0), which has PKCS #11 support since a few weeks now, libsoup has no infrastructure for handling client certificates at all [1] and GnuTLS does not seem to handle that by itself the way NSS does. There are efforts to support TLS within GIO context and to provide a plugin mechanism (so several security libs could be used) [2], but this will take time to be implemented and so it won't help us right now. This means that we cannot use libsoup for HTTP access since we *must* be able to support client certificates. We will have to look for another solution for now. I also do not like the idea of adding yet another dependency to some other HTTP lib which has NSS support (like libcurl) too much, but which other options do we have? If we used libcurl, then we needed to provide our own packaged version which will be linked against NSS, since most distros ship only openssl/gnutls variants. I'll be very grateful for any further input. Kind regards, Christian [1] http://mail.gnome.org/archives/libsoup-list/2010-August/msg4.html [2] http://mail.gnome.org/archives/libsoup-list/2010-August/msg1.html -- 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: Camel.HttpStream in the wild (?)
Hi there, On Thursday 05 August 2010 Matthew Barnes wrote: On Thu, 2010-08-05 at 18:30 +0200, Christian Hilberg wrote: Result: While libsoup should build against the current GnuTLS lib (development version, 2.11.0), which has PKCS #11 support since a few weeks now, libsoup has no infrastructure for handling client certificates at all [1] and GnuTLS does not seem to handle that by itself the way NSS does. Hmm, then perhaps CamelHttpStream might be a good stopgap after all. Be aware that I have marked it as deprecated and do still plan to remove it after we transition to WebKit, but perhaps by then Dan's TLS work for GIO will have landed. Since we are developing against Evo 2.30, my thoughts are the same. I'll try to wrap up CamelHttpStream usage in a way that should make it easy (hopefully) to replace CamelHttpStream by some true HTTP lib later on. Thanks and 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
Re: [Evolution-hackers] evolution-kolab: Camel.HttpStream in the wild (?)
Hi Stef, On Friday 06 August 2010 Stef Walter wrote: [...] FWIW, gnutls is working on PKCS#11 support. The first bits have been added and I've been working with the gnutls maintainers on some of the remaining parts. I believe libsoup will start using this in the near future. Yes, we've seen that. Sadly, it won't help us right now, but it is good to know that we'll be able to drop CamelHttpStream once this will be working. [...] You might be interested in the talk that I gave at GUADEC which addresses this and outlines our current effort to make things like client certificates and key storage work far simply and reliably across GNOME. http://stef.thewalter.net/2010/07/my-talk-usable-crypto-on-gnome.html We'll check that out, thanks for the bits! :-) 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: working with multiple Camel.Provider instances
Hi. In the backend code for our plugin, we will need to handle two IMAPX providers simultaneously, one for the address book backend and one for the calendar backend. Normally, there will be a single Camel.Session instance only. Will this be true in our case as well, when there are multiple Camel provider instances of the same type (i.e. IMAPX)? Note that each provider should cache it's data separately. 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] Camel IMAPX RFC5464 compliance
Hi everyone, On Thursday 05 August 2010 David Woodhouse wrote: On Wed, 2010-08-04 at 12:22 +0200, Christian Hilberg wrote: Now, I would like to know how we should deal with the issue. We (the evolution-kolab developers) could patch the 2.30 version of IMAPX only to get things running. In this case, would our additions be pulled upstream? [...] I would strongly recommend that you do it in the development branch first, then we can backport it to gnome-2-30. I've been backporting most IMAPX changes from master to the 2.30 branch; I see no particular reason why we shouldn't backport METADATA support too, as long as you're careful not to add new user-visible strings that would need translation. Okay, let's say, we will patch upstream IMAPX to support RFC5464. The patch gets reviewed, and after being polished it will (hopefully :-) be accepted in upstream. How long do you think it would take you to backport such a patch to 2.30, assuming we heed to the aforementioned implementation recommendations? 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: 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
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: Subclassing and extending IMAPX
Hi everyone. After some time working on different places within our Plugin, I'm back to our IMAPX part. braindump 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 care
[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
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: 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
[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: 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
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 BirthdayAnniversaries 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 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
[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] 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
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
[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] 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
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
[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
[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
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
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 about that here: http://live.gnome.org/TranslationProject/DevGuidelines Hum. We're set up to use intltool/gettext, but no translation has taken place as yet. Moreover, the release of gnome-2-30 has vanished into history, so I assume it will be okay to push master from SF-Git to GNOME-Git and start translation preparations for a later (3.x) release
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] 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 branchcommit 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] 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 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, 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
[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] 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
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] [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
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] 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] 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] [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 -- Thread: http://mail.gnome.org/archives/evolution-hackers/2011-April
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] 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] 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 IMAP|POP|SMTP|... 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] 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 IMAP|POP|SMTP|... 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 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
[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] 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 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 Kolab client hase decided that exactly *this* would be the UID string it would want to use today. Granted, this is a corner case and it should hit so very seldom that manual intervention would be acceptable. My point is, that you might be very well able to make good use of UUIDs if you implemented a fully new system, which would enforce all clients to be using UUIDs and all servers dealing with objects checking that the UID
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 UUID. 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
[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] [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] 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] IMAPX code dependency
Hi Matt, Am Freitag 03 Februar 2012, um 16:46:50 schrieb Matthew Barnes: On Fri, 2012-02-03 at 15:53 +0100, Christian Hilberg wrote: I need to replicate some code paths of IMAPX (e.g. all paths that lead from the Store to imapx_untagged, so I can extend this one for ANNOTATEMORE and later IMAP ACL). Hence, there is some IMAPX code duplication I cannot avoid at present. This means that for every (major) change in upstream IMAPX, I need to pull the changes in and check whether I need to fix something in my code dupes. Would it help you much to turn imapx_untagged() and similar functions into virtual class methods in CamelIMAPXServerClass? Then you could override the method in your subclass, and have it chain up first and then do other custom stuff. That would definitively make things easier. As far as the CamelIMAPXServer goes, extending imapx_untagged is the main objective. In fact, for 2.30, I've added a few more switch cases to imapx_untagged and did no more than calling one of my own functions there. (I did a little more - we've talked about that table based approach where I turned almost all of that giant switch statement into a function table, leaving only a few case's to be handled - it is all there in evo-kolab's gnome-2-30 branch, but has never gone upstream). Or does the logic not allow you to break things out that cleanly at present? (wouldn't surprise me) I don't think that my own logic would get into the way here. Now that you've mentioned it - we were thinking and talking on IRC how to change imapx_untagged for a table-based approach (a function table that is, with one handler function per untagged response and its index being the untagged response code). For that, I think you mentioned a vtable bound to the object (class?), to make the whole thing extendable. I see the imapx_untagged-upcall you mentioned above fit into this scheme. Extend the vtable, and in your local implementation of imapx_untagged, call the parent object's imapx_untagged first, then check whether the response has already been handled (in which case you're done and return), or whether parent's imapx_untagged tells you that there is a response pending and still unhandled, so you, the derived class, may have a handler for it. You check, and yes, you have an entry in your extended vtable for the particular response code (means, the list of known response codes also needs to be extendable, that could be a tricky part with the current gperf thing for generating that), and you call your handler. That is, with the untagged response code, index into the vtable, get the function pointer and make your call. imapx_untagged would be required to set a specific error if the untagged response could not (yet) be handled. As the implementor of a subclass, after upchaining to the parent handler, this would allow me to decide whether there may be work left to do and I can check whether I have a handler for it. If I do _not_ have a handler, I do propagate that error, so either a subclass of mine would know that there may be work left to do, or the original caller would know whether there was no handler for the response code in the inheritance chain. Whether or nor a parent's existing handler for a specific untagged response could be sensibly overridden with this construction might be worth discussing (or whether it should even be possible - might not be a wise idea to make that possible). Dumping a few bits, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 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] 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 state by way of g_network_monitor_can_reach(), but I'm holding off on that until my account-mgmt branch is merged, so EBackend will have a consistent way of getting the server address to feed to GNetworkMonitor. Still, seems doable by 3.6. Well okay, that's a little more than the current EBackend online property, since it can
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
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] 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 the better one here). -- ad c) The mailer part does this in global, not per-account bases. Maybe the client may have this done in the same way. Nonetheless, in a multi-client environment you may make sure that the clients will not fight on this (when one requests backend to stay offline while the other
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, ...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, 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, 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 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 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
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
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
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
[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] PIM server synchronization and Evolution online/offline state
Hi again, Am Dienstag 03 April 2012, um 10:52:00 schrieb Christian Hilberg: While porting evolution-kolab from Evolution 2.30 to 3.4.x (and on to 3.5 later on), I have been stumbling upon an issue regarding groupware server synchronzation. [...] Effectively, I am lacking a mechanism which tells my backend that the user wants to synchronize the local cache (evolution-kolab implements a full offline cache with offline-editing support) with the Kolab server side. [...] In our lengthy discussion about that topic, we found that a synchronize() method is desired for the backends and EClient would expose this in its API. How exactly the various E-D-S clients will represent this functionality in their GUI needs to be discussed, but I think this detail is secondary to the former (i.e. the communications infrastructure which makes it possible to send a synchronization request to the backends, which they can then handle in their very own fashion). Have there been steps taken already towards implementing this infrastructure? Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Subclassable and extendable IMAPX
Hi all, Am Dienstag 08 Mai 2012, um 11:52:00 schrieb Christian Hilberg: It has been a while [0] since the idea of making IMAPX subclassable / extendable for backends to use. Time to bring the topic back into the public again. :-) There is a bugzilla entry [1] now for the topic, and Chen bravely started out with preparations to make IMAPX extendable. [...] While trying to make use of Chen's initial approach to making IMAPX extensible, it has shown that this approach is a little bit too basic and does not lead to the structural improvements inside IMAPX which we've been hoping for. There are some other issues with this approach, too, so we had to rethink the whole thing. As I had made a local copy of IMAPX extensible for evolution-kolab back in 2.30 era using a function table for untagged response handlers, I decided to implement this for upstream IMAPX (while evading some issues I had in 2.30 - live and learn ;-). The result of my work lives in the 'imapx-extensible' branch of E-D-S. It is still work in progress (the IMAP capabilities flags need to be made extensible, too), but it is already working and imapx_untagged() lost most of its amazements. All (IMAPX) devs interested in what has been done so far are welcome to check out 'imapx-extensible' and have a look around in CamelIMAPXServer and friends. Kind regards, Christian [0] http://mail.gnome.org/archives/evolution-hackers/2010-September/msg00012.html [1] https://bugzilla.gnome.org/show_bug.cgi?id=674310 -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] PIM server synchronization and Evolution online/offline state
Hi, Am Mittwoch 09 Mai 2012, um 09:28:53 schrieb Milan Crha: On Tue, 2012-05-08 at 10:56 +0200, Christian Hilberg wrote: @Milan: Do you think you could post your API work here at e-h list? That would give us something to base our discussion on. Even if no GSoC student picks up the topic, your work should not be lost. Hi, sure, the initial draft is attached. I'm not attaching our conversation around it, as it was long, even it might clarify certain things. As a starter, let's call it EBackendOfflineCache, not as the initial draft calls the base structure EBackendCache. As far as I can tell, it is capable to satisfy all needs from Kolab, I tried to draft it in an extendable way. Has someone been working on this thing yet? Kind regards, Christian -- kernel concepts GmbH Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ signature.asc Description: This is a digitally signed message part. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] 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
