Re: [Evolution-hackers] evolution-kolab: Lifting the veil

2010-07-10 Thread chen
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

2010-07-09 Thread Christian Hilberg
Hi there,

On Thursday 08 July 2010 at 19:01:25 Matthew Barnes wrote:
 [...]
 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).

Our present status is that we set up the project as a standalone plugin. This 
way, development will be easier for us to handle. If there is no objection 
from Evo developers' side, we will make this decision permanent.

 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.

So far, we do not see this separation as a barrier. Lets hope this holds true 
in future as well. ;-)

 The process for obtaining a gnome.org account is here:
 [...]

Thanks for the explanation. We'll get back to that later on, when there is 
something sensible ready to be pushed into the repo.

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: Lifting the veil

2010-07-09 Thread chen
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

2010-07-09 Thread Sankar P
 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

2010-07-08 Thread Christian Hilberg
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

2010-07-08 Thread Michael Meeks
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

2010-07-08 Thread Matthew Barnes
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

2010-07-08 Thread Christian Hilberg
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