[Kde-pim] Re: Announcing KSmtp - A KJob-based SMTP library

[Jan Kundrát]

On Thursday, 27 December 2012 23:01:26 CEST, Allen Winter wrote:
> KDE SC 4.11 is open for new additions so now would be a good time to start
> the process of moving ksmtp lib from playground.

Hi, I'm looking for a replacement SMTP client for Trojita. I've got a couple of questions for KSMTP:

1) How do I build and execute the tests? I've configured like this:

mkdir build && cd build
cmake -DKDE4_BUILD_TESTS=1 -DCMAKE_BUILD_TYPE=DebugFull ..
make -j6

...but there's still no `make test` or `make check`. After running `make ksmtp-test`, one more executable gets built. Looks like I don't know some convention which defines what to pass to cmake to build usable unit tests.

2) When I cd into the tests subdirectory, I can launch `./ksmtp-test.shell` and `./ksmtp-test`, but they both appear to be stuck in the "SmtpTest::testHello(EHLO OK)". How shall I invoke them?

3) It looks that the tests (tests/fakeserver.cpp) are actually communicating over a local TCP connection. I agree that this has a very strong benefit of actually being able to test the actual socket handling code, but due to a hardcoded port number, it looks like this is a rather fragile mechanism and also rules out parallel tests.

4) In Trojita, there's an abstraction layer built on top of QIODevice. This allows us to use a QTcpSocket or a QProcess transparently and allows stuff like connecting to your IMAP server via SSH. The same abstraction is used for tests; it allows us to use a code like this:

	cServer("* OK carry on\r\n");
	cClient("a0123 SELECT INBOX_zzz\r\n");
	cServer("a0123 NO No such mailbox\r\n");

The application/library code either gets their sockets from the callers or use a factory class to instantiate them. The unit tests are then configured to use a special factory which returns these mocked SOCK instances to work on.

The fact that Trojita's unit tests don't use TCP is pretty much irrelevant here, but the important part is the ability to use a unified API for both TCP and SSL connections. For IMAP, it is crucial (`ssh mail.example.org dovecot --exec-mail imap` combined with an ssh-agent is a wonderful way of accessing e-mails); for SMTP, not so much due to the pretty standard `sendmail` binary, but it would still come handy for some users.

Is there an KDE equivalent of this? The API I use is at [1].

5) Trojitá does not require any KDE library, and I'd prefer not to start requiring them just for KSMTP. It looks like KSMTP is currently using KJob, i18n(), kDebug() and KMIME. What would be the preferred way of using the KSMTP in a KDE application which does not want to even link with kdelibs unconditionally?

6) There's no support for BURL. Trojitá's SMTP code does BURL, and if we switch to KSMTP, I'll be happy patch it to work with BURL as well. The BURL extension is a mechanism which lets the SMTP server download the message to be delivered from an external place, typically the IMAP server. In short, when it works properly it turns the "upload once to the Sent folder, then upload again via SMTP, set some IMAP flags after that" into a "upload to the Sent folder, generate an URLAUTH token, ask the SMTP server to send it, set some IMAP flags". It saves at least half of the data to be uploaded, amking it very attractive for mobile clients (and possibly even more with CATENATE etc).

So, would you guys be happy with patches which somehow change the 5) above?

With kind regards,
Jan

[1] http://quickgit.kde.org/?p=trojita.git&a=blob&f=src/Streams/Socket.h

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/