[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:       Michael =?iso-8859-1?q?H=E4ckel?= <Michael () Haeckel ! Net>
Date:       2001-06-21 12:32:33
[Download RAW message or body]

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. However this code now relies on some code 
that is no longer present, but this problem is solvable.

>   - 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.

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.

Aaron just wanted to finish this for a special need, and this special need 
can also be fitted with an inofficial patch against the released version. We 
actually anyway din't any longer expect this code in KDE 2.2 independant of 
the ksasl problem.

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.

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.

A mail client is simply an application that will be never feature complete.

>   - KSASL was removed.  This needs to be rewritten.  I don't think it's a
> huge undertaking but once again, we need this.

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.

>    I say again....  Let's slow things down, think over our plans for 2.2
> and what we wish it to be, and fix the things that really need to be fixed.
>  2.2 will be the third major release (2.0,2.1,2.2) in less than a year. 
> That's a very impressive release schedule.  I don't think anyone can
> complain if it's closer to the end of that first year.

I only don't understand, why we do have a release schedule then.

I simply don't like moving annouced released date by that much time. That 
slows down development for all people that care for the schedule and try to 
be ready in time.

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.

Regarding these unforseeable issues:

- Some kwin styles were removed, now they are back, so where is the problem?

- 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.

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

Regards,
Michael Häckel

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