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/ _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development