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

List:       kde-core-devel
Subject:    Re: Upcoming 2.2 release schedule, bickering and bugs
From:       Don Sanders <sanders () kde ! org>
Date:       2001-06-21 15:30:24
[Download RAW message or body]

I'm glad to see George cares for this issue, and that he 
takes the attitude that we should "salvage what we can and 
move on."

But I disagree that we should delay the release because of 
this problem.

On Thursday 21 June 2001 14:32, Michael Häckel wrote:
> On Thursday, 21. June 2001 08:11, George Staikos wrote:
> >   - We have issues with kio_smtp and kio_pop3
> > licencing, if I'm not mistaken. These are critical
> > components and must be fixed.
>
> We don't have a licencing problem with kio_pop3. This
> code is still under a BSD style licence as it ever was.

Verified.

> However this code now relies on some code that is no
> longer present, but this problem is solvable.

Michael if you can solve this problem that would be great.

> >   - kio_smtp _really_ needs to be implemented in KMail.
> >  I know that Aaron is working on this and he _must_
> > need more time.  We need to support SMTP Auth and it
> > would be very nice to see SSL and TLS support too. 
> > Also, we all know that having two copies of the same
> > code, one of which is non-reusable, is a waste of
> > effort.
>
> Of course, but this is not a show stopper for KDE 2.2.
> This can also be done later. KMail is currently also able
> to send mails very well without this code.

Agreed. The (non-blocking) smtp code in KMail is a 
significant improvement over 2.1, and the events that have 
transpired do no adversely affect the current smtp 
implementation in KMail.

> We didn't have SMTP auth in KDE 2.1 so it is not a real
> loss for users if we still don't have it in KDE 2.2. This
> feature was simple not ready in time for various reasons,
> therefore it has to wait.

I believe KMail supports SMTP auth, but it requires using 
sendmail rather than direct smtp.

I asked someone to write a HOWTO on this.

However smtp auth support better integrated with KMail is 
definitely in high demand.

...
> We had a similar issue to times of KDE 2.1. A lot of
> people absolutely wanted to have IMAP support in KMail as
> part of that release and even asked to delay the release
> because of it. I rejected that, because it was simply not
> in a releasable state at that time. However now it is
> very stable and ready for a release. Well a few features
> are still not present, but it is stable and useful for a
> lot of people as it is.

I think this decision was an important one and I think you 
made the right choice. Releasing IMAP support prematurely 
would of resulted in wide spread dissapointment.

> Now we should delay the release of an IMAP enabled KMail
> only because we don't support SMTP authentication yet.
> Where is the logic here? Yes, SMTP authentication is a
> nice feature, that should be implemented as soon as
> possible, but a lot of users can also live without it.

Yes. IMAP support is ready and a KMail with IMAP support 
should be released.

...
> We _do_ have GPL code that is capable to doing CRAM-MD5
> authentication. This code in only currently not of
> library quality and doesn't use qt strings internally but
> works very well.
> I only switched the imap slave to use ksasl some time ago
> in favour of less code duplication.
> Reimplementing AUTH PLAIN can probably also be done in
> around three lines of code.

Please do this.

...
> At least KMail is in a releasable state now and we
> already have some features waiting for after the release
> that are already partially ready. For example maildir
> support or serial identification numbers to fix for
> example Bug#128.

I agree KMail is ready for a beta release but more time 
spent fixing bugs would be beneficial. (I found a 
reproducable hang yesterday).

...
> - KSASL was removed. AFAIK kio_pop3 and kio_imap are the
> only parts of KDE (besided kio_smtp we not neccecarily
> need) that use this code. For kio_imap this is not
> problem as mentioned above. For kio_pop3 I either disable
> SASL or temporarily copy a function for CRAM-MD5 support
> (50 lines of code but using char*) over. SASL is anyway
> rarely used with POP3 and we also didn't have this
> feature in KDE 2.1.

Please just copy the code over.

> At least for KMail, which is probably most affected by
> this problem we don't have to wait.

Then we should proceed according to schedule.

Don.

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