Re: [Evolution-hackers] evolution-kolab: Lifting the veil
On Fri, 2010-07-09 at 14:22 -0400, Matthew Barnes wrote: On Fri, 2010-07-09 at 10:29 -0600, Sankar P wrote: (oh that out-of-tree Scalix backend is still using flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types) Is evolution-scalix even alive? It hasn't seen a release in over two years. Same goes for evolution-jescs. How about having all the collab-backends into a single package ? evolution-collab-backends, which can hold exchange, groupwise, mapi, kolab, (google?) etc. ? Any cons that you see ? At-least we wanted to keep the backends such as Imap, pop, caldav, etc. which were independent component providers inside eds itself. - Chenthill. ___ 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 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 13:01 -0400, Matthew Barnes wrote: 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. While thinking about this, I just got a thought of why not a, evolution-collab-backends package which can hold all the eds collborative backends (that provides mail+calendar+address-book) such as mapi, exchange, groupwise with sufficient configuration options to choose what to compile ? This would help in making the api changes to all backends and keep external backends connected. I support maintaining the backend code in a separate package though. Its easier to provide updates to the backends if its not part of eds at-least with some distros (at-least with suse as I use it). - Chenthill. 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 ___ 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 7/9/2010 at 09:44 PM, in message 1278692045.6831.33.ca...@linux-e1q4.site, chen pchenth...@novell.com wrote: On Thu, 2010-07-08 at 13:01 -0400, Matthew Barnes wrote: 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. While thinking about this, I just got a thought of why not a, evolution-collab-backends package which can hold all the eds collborative backends (that provides mail+calendar+address-book) such as mapi, exchange, groupwise with sufficient configuration options to choose what to compile ? This would help in making the api changes to all backends and keep external backends connected. I support maintaining the backend code in a separate package though. Its easier to provide updates to the backends if its not part of eds at-least with some distros (at-least with suse as I use it). More modules translate to more problems trying to build things. Oh I need to git clone another 10 modules. In my opinion, we should just follow linux kernel filesystems style (all under one tree). There can be any number of backends, but we can use sane config options to build only interested backends (for instance someone working on RHT may not bother about GW etc.) But for someone who wants to build evo with all backends, it is just one 'git clone' that he needs to do. Also, during release time, more modules contribute to more work for the maintainer(s). Changes made in core may not reflect in some low priority backends, if they are kept out of the tree. (oh that out-of-tree Scalix backend is still using flat-file-summary-APIs-oh-wait-lets-ignore-it etc. types) However, I am a little out of touch with the things and so I trust Chen/Matthew 's decisions as they know the current state. Just my 2 cents. Sankar - Chenthill. 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 ___ 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 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
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
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
