28 Mar
2019
28 Mar
'19
12:19 p.m.
Hello all,
I have started this discussion in the forum[1], but apparently this mailing list is more
appropriate. So, below is my original post, followed by Holger's reply with my answers
to that inline.
There might be a misunderstanding. My list does not contain any implementation details.
Quite the opposite: before taking the first incremental step, we should first decide on
the direction in which we want to go. And that's where the 4 approaches come in.
Except for maybe approaches 3 and 4, the different approaches are not incremental
extensions of each other. So we will probably need to decide which way to go, and discuss
enough details to make the decision.
For example, the sending half of approach 1 is a single trivial function, because most of
the work for that was part of the "early MIME generation" issue. It already
technically accomplishes the goal of sending arbitrary MIME mails, except that
accomplishing the goal this way is almost useless because it forces clients to do
everything on their own, from MIME generation to crypto (see also the cons in the list).
"Semi-arbitrary mime-mails" sounds to me like approach 4: adding functionality
to the Message class to send more and more types of mails until it's flexible enough
to send any MIME mail. So yes, that's one approach which would make sense. But before
we start discussing the implementation, I would like to discuss the pros and cons relative
to the other approaches. And maybe somebody can come up with yet another completely
different approach.
As a
pre-requisite for "Make DC a replacement for MUAs?"[2] and hybrid
chat/mail clients in general, the DeltaChat Core library should support
sending and receiving arbitrary MIME mails.
I see several ways to add the API to DCC, in order from least to most
abstraction:
1. Send/receive raw bytes. Not stored in DCC database.
Folders are simply strings representing the full path, i.e. starting
with “INBOX/”.
- pro: least effort for DCC
- con: most effort for DCC clients, duplicate DCC functionality
- con: need to expose more internals to access e2ee keys, etc.
2. New class allowing direct access to libetpan. Optionally stored in DCC
database.
Folders have their own class.
- pro: reduced effort to implement now
- con: more effort for clients on migration away from libetpan
3. New class with all necessary methods, abstracting libetpan. Optionally
stored in DCC database.
Folders have their own class.
- pro: reduced efforts for clients
- con: more effort to implement now
- con: more effort for DCC to migrate away from libetpan
4. Extend the existing message class (dc_msg_t). Stored in DCC database.
Folders can use either their own class or extend the existing chat
class (dc_chat_t).
- con: big change to existing APIs, code and DB
- con: gets in the way / increases the learning curve for pure chat
clients
Just counting the pros and cons, options 2 seems the best so far. But
before we start thinking about implementation detail, what are your
thoughts and ideas about it? Maybe some completely different
implementation ideas?
Not sure this is a good forum for discussing what are rather implementation APIs and
architecture questions. I’d rather suggest the mailing list. Let me still say a few things
:)
I suggest to think more about the needed API and not too much about how it’s implemented.
There is a lot of tentative/incremental flux that could happen in the next months,
regarding moving code from C to Rust etc. And let’s maybe first talk about
sending/receiving semi-arbitrary mime-mails, not about new/added IMAP handling. Which
C-API would be needed and how would it work/be specified? How does Autocrypt-handling happen including
encryption and decryption? If mime-mails are not tied to a chat at sending time, but to a
caller-specified list of recipients, then how are they accessed on the receiving side?
I'm not sure I understand the question. Mails are accessed using a mail client, aka
MUA (mail user agent). Why should anything be different if the sender's MUA is using
DCC instead of e.g. MailCore 2?
Regarding Autocrypt, that should not be any different than people accessing their
Autocrypt-encrypted mails on multiple devices/clients. The beauty of chatting over email
is that for the purpose of most standards (here: Autocrypt), DeltaChat is just another
MUA.
Regards,
Viktor Pracht
[1] https://support.delta.chat/t/support-normal-mails-in-dcc-for-hybrid-clients…
[2] https://support.delta.chat/t/discussion-make-dc-a-replacement-for-muas/253
--
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe
AG Siegen, HRB 8718
Geschäftsführer: Frank Hoberg