[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] LFS in evolution-data-server
Hey there, I'm the current evolution/eds/gtkhtml maintainer in Debian, and I'd like to ask a question. I recently enabled large file support in evolution-data-server in Debian. It seems that it leaded to the discover of some bugs on i386 installs (like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580419 / https://bugzilla.gnome.org/show_bug.cgi?id=612082 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585921 / https://bugzilla.gnome.org/show_bug.cgi?id=619098) which leaded to crashes. Not all bugs are caused by LFS, but it seems that enabling it leads to use infrequent/less tested code paths, which lead to bug discovery. It seems like a good idea to fix bugs and not hide them, so I'm fine with that, but I have someone asking to disable LFS support for Squeeze (we're trying to freeze at the moment) so the bugs revealed by LFS support stay hidden. The bug asking for that is at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588316 basically saying it's safer to disable it for now and re-enable it later in unstable. I'm not completely against disabling it (it wasn't enabled before, like in Lenny) but it's a release goal for us, and all in all it seems like a good idea to be able to support large files. I don't know if a lot of people have 2/4G+ files on their evolution install, and only 32 bit users are concerned (but that still means quite a lot of people), so I'd like to ask upstream advice on this. What do you think of the LFS support, should it be considered stable and enabled (and eventual bugs fixed asap) or should I still keep it disable for now? Thanks for your help, -- Yves-Alexis ___ 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 Christian, You write-up sounds really exciting :-) 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. > * targeting Linux for client and server *solely*. No specific attempts will > be made to be portable to other platforms (like *BSD, Windows, ...). That is quite normal; Fridrich loves to port stuff to Windows ;-) and as you say using the right platform libs should make that easier. > * 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. Unfortunate, but understandable :-) > * 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. Ah - each distro will package it their own way. > 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. 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. > Our customer, for whom we will develop this solution, is also very > specific about the project being hosted publicly and accessible by everyone. Wonderful :-) > 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. ;-] ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot ___ 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] Heads Up: More Camel API breakage in 2.31
I finally finished converting Camel's error handling code to GError. CamelException is no more. I plan to push this later today after a bit more testing. It will debut in 2.31.5 along with another libcamel soname increment. As boring an announcement as this is, it's actually pretty important in moving Camel closer to embracing GIO. To that end, failable disk and network I/O functions in Camel will now set G_IO_ERRORs [1]. Also, for cancellations, G_IO_ERROR_CANCELLED replaces CAMEL_ERROR_USER_CANCEL. Next step is introduce GCancellable into Camel's blocking API. But that's a much more disruptive change and I'm not sure if that will land in time for 3.0, as I need to turn my attention to other higher priority projects for awhile. Matthew Barnes [1] http://library.gnome.org/devel/gio/stable/gio-GIOError.html ___ 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
On Thu, 2010-07-08 at 16:01 +0100, Michael Meeks wrote: > > 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. ;-] Certainly aim for hosting your project on git.gnome.org, but I'd still prefer it be split into a separate evolution-kolab repository similar to evolution-exchange, evolution-mapi, and soon evolution-groupwise (I'm told). It just keeps things more modular and it keeps us honest: our public APIs -have- to be complete since external projects don't have access to private in-tree APIs. The separation is not meant to be a barrier between you and us, just an implementation detail. The process for obtaining a gnome.org account is here: http://live.gnome.org/NewAccounts Each of your developers should apply for their own account, but I would suggest waiting to do this until after you have a working public beta, as you'll have more credibility to the gnome.org admins then (which is not us!). Once you have your gnome.org accounts, you can clone your git repository on git.gnome.org by following the procedure here: http://live.gnome.org/Git/NewRepository Hope this helps. ___ 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
