On Monday, 20 April 2015 21:12:44 CEST, Franz Fellner wrote:
Is it really necessary to use a multiprocess web framework just
to view HTML mails?
I suppose that it is necessary to use an HTML content renderer which:
- is still supported,
- remains reasonably secure and up-to-date,
- provides sufficient features to make sure that users' privacy is not
compromised.
Whether it implies using multiprocess architecture or not is an internal
implementation detail. We might think that it's an overengineered beast,
but our opinion is not as important as the opinion of the guys who are
doing the actual work.
Can't this be done with different backends, so users/distros
have the option to simply use KHTML?
I cannot speak for KDEPIM, but I can speak for Trojita which is currently
using QtWebKit.
Based on a quick glance through the KHTMLPart's public API, I cannot use it
in Trojita. One of the reasons is that HTML e-mails use the cid: URL scheme
for accessing data from other MIME parts in the same message. I don't see
any way to implement custom URL schemes *and* to disable arbitrary network
access on a per-message basis at the same time.
The e-mail clients unfortunately ar especial; their use case is much
different from a web browser model, they cannot work through a "just render
this HTML you read from this QIODevice", and at the same time thay are
expected to render rich HTML with full support for modern CSS. I'm not
surprised that KHTML's API is not sufficient; the QML-based API of Qt's
WebKit2 wasn't sufficient, either.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
