[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] libkmime status.
From:       Volker Krause <vkrause () kde ! org>
Date:       2006-10-10 13:56:54
Message-ID: 200610101556.54815.vkrause () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 10 October 2006 12:10, Tom Albers wrote:
> Attached are two patches, maybe you can review them. First one adds the cc
> and bcc fields to the essemble() method, kind of a showstopper for a
> mailclient ;-)
>
> Second one adds the User-Agent header to the essemble() method and moves
> the userAgent(bool) from the newsarticle to the message. (newsarticle
> inherits message).

Both patches look good to me. They clearly show that KNode has only very 
limited mail support ;-)

> What's  the state of the branch, can I commit there straight away, is it
> frozen? Any policy on porting to kde4 that I should know?

Offically there is a feature and message freeze in branch, but I wouldn't mind 
if you commit your patches there. Forward-porting to trunk is of course 
needed, but I can do that if you don't have the possibility to do it.

> > I've read that you are writing your own mail client, so I wanted to talk
> > with you about collaboration anyway. The vision for KMail/KNode in KDE4
> > is splitting them into a couple of reusable and interchangeable
> > components (viewer, composer, header list, identity management, account
> > management, mail transport, etc.). That makes it very easy to eg.
> > implement alternative UI concepts without making the existing code very
> > complex or having to do everything again. Maybe some of these parts are
> > interessting for you as well, so we could also share some work there.
>
> Yes. Although I'm not interested in being a core library hacker, I want to
> make easy, intuitive applications. When I write a part that can be reused
> by others, a lib is ok of course.

Sure, a messageviewer KPart is technically a library, but you barely notice 
that when hacking on it. So, no need to become a "core library hacker" ;-)

> > > 2) The headers are not installed, that means there are currently no
> > > distro's carrying the development files to compile my application. Can
> > > this be changed?
> >
> > There is only one reason libkmime has not yet been moved to kdepimlibs
> > (and thus becoming public API for KDE4): the license. It's currently
> > mostly GPL v2, once we finally manage to change it to LGPL, it will move
> > to kdepimlibs.
>
> What needs to be done for that? Is someone already arranging that?

I'm not aware of anything going on here. It would require permission by all 
authors I guess. From what I can see, these are mainly Marc Mutz and 
Christian Gebauer, there are also smaller contributions by Ingo, Zack and 
myself as well as some porting work by Laurent and Reinhold. Several other 
people seem to have committed just a few lines each, not sure if permission 
is needed from those as well. Unfortunately most of the code was history-less 
moved/imported at r111113.

IIRC Marc was against changing the license in 2004.

@Marc: Would you still object a license change of libkmime to LGPL? Changing 
the license would allow us moving it to the new module 'kdepimlibs' where it 
would become public API and could be used by every KDE application (similar 
to being in kdelibs).

regards
Volker

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]