29 Mar
2019
29 Mar
'19
11:54 a.m.
holger krekel <holger(a)merlinux.eu> hat am 28. März 2019 14:09 geschrieben:
Hi Victor,
i'd like to focus in this thread on the API issues
with non-chat "normal" mails ...
On Thu, Mar 28, 2019 at 13:19 +0100, Viktor Pracht wrote:
When considering sending/receiving non-chat mime-messages:
- sending: how does Delta Chat persist the message?
currently a message always relates to a chat id,
i.e. there is precisely one chat for each message.
How would UIs access non-chat messages
when they want to display it later? Or would the messages
be stored outside of DCC's DB and DCC would only
perform Autocrypt processing before sending it out?
With approaches 2 and 3 [1], either option is possible. If stored in the DCC DB, mails
would have their own table(s).
With approach 4, it would be part of the existing messages table in the DB. Instead of
always referring to a chat, the ID could then alternately refer to an IMAP folder. Since
(as I just looked up) the recipients of a message are stored in the chat, mails would need
to store their sender and recipients somewhere else.
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? - receiving: with which chat is an incoming
message associated?
The chat detection logic wouldn't change. Non-chat mails are not associated with a
chat. That's what makes them non-chat mails. They would be associated with an IMAP
folder where the user and/or Sieve filter rules placed them.
How is it persisted
and then accessed/noted by a UI?
Persistence would be the same as for sending (i.e. optional for 2 and 3, mandatory for 4),
except that sending implicitly uses only the "Sent" folder, while received mails
can be in any folder. So mail storage would need to remember the folder ID for mails
instead of the chat ID for messages.
Which events are emitted?
No idea. I would like to have an overview of existing events during a message's life
cycle as documentation anyway. Then we can add any events which are missing. Off the top
of my head I can think of an event when a mail is moved to another folder, but that's
hard to detect when another client does it. Most events are probably identical to or a
subset of message events.
- there also are questions on how Autocrypt
plays into the sending/receiving side
but i *guess* there are doable so i leave
that aside for the moment.
I also think the handling of Autocrypt by one or more email clients is the main use case
of Autocrypt, so it should be straight forward to apply it to an email client and a
chat-over-email client.
if these questions still do not make sense i am happy
to do an a/v about this topic sometime :)
I think my only problem with understanding was that I didn't have in mind that
recipients are stored in the chat and not in the individual messages. That's yet
another difference in the data models between mails and messages. Which results in yet
another complexity for approach 4, which in turn makes me like approaches 2 or 3 even
more.
Regards,
Viktor Pracht
--
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe
AG Siegen, HRB 8718
Geschäftsführer: Frank Hoberg