[Development] Proposal: "rebranding" QMF as QtMail

[Jan Kundrát]

On Monday, 17 February 2014 12:25:44 CEST, Robin Burchell wrote:
> If you have proposals for other changes, I'm open to hearing about
> them. In general, I don't think most of the usability of the API is a
> problem apart from a few occasional trouble points, but different
> perspectives are always interesting.

When I looked at the QMF's APIs, my biggest gripe with them was that they 
are essentially an all-or-nothing solution in that it forces you to use the 
whole of QMF even for relatively simple needs like sending an e-mail.

One example -- I wanted to replace Trojita's SMTP implementation (which 
itself comes from another project) with something more robust. The QMF's 
SMTP code is not self-contained at all. I would like to get a class with 
relatively simple API for specifying the connection options in a couple of 
enums and strings, and passing in the data to be sent as a QByteArray. The 
src/plugins/messageservices/smtp/smtpclient.cpp, however, needs passing 
around a QMailAccount, requires access to QMailStore::instance(), and the 
message payload itself is being passed as a QMailMessage [1]. 

Of course I do recognize that there is value in having convenience 
functions like "hey, my SMTP configuration is already in this QMailAccount, 
and the message I'm sending is here in a QMailMessage". What I would like 
to see is, however, separation of these different functions into multiple 
layers. That way, I could only use the actual SMTP protocol implementation 
without having to worry about bringing a ton of extra compatibility shims. 
The SMTP code actually *does* work with simple QByteArrays which it 
extracts from a QMailMessage at some point. Why do I have to construct this 
transient representation in the first place?

Also, from the overal architecture, QMF appears to really like to have a 
central storage of the mail messages. While this is very reasonable 
architecture for an e-mail client, it might not make a lot of sense to 
impose this from within a general purpose library. Suppose someone is 
adding a feature for sending a PDF report via mail to their existing Qt 
application -- do they really have to bother with settings up and 
configuring some mail storage to point the QMF at?

Disclaimer: I'm a developer of a competing e-mail client, so my needs might 
(or might not) be very different from what a casual developer who "just 
wants to send a mail" might expect. Again, having high-level APIs for 
building MIME messages from parts and sending the result to an e-mail 
address is something extremely convenient and valuable, but it should, 
IMHO, be provided *on top* of the lower-layer building blocks.

With kind regards,
Jan

[1] Yes, BURL needs something "better" than a QByteArray, but there are 
still many ways in which one could make it working without tying the API 
into one particular representaion of everything.

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/