Architectural Overview

[Ezbob]

There is a preliminary overview of the architecture in the wiki now. Please review it and let's discuses what needs to be fixed.

[xiroV]

Great! Looks good!

I'll try to write down the things I've thought about regarding the layout, based on your diagram:

• We need a SMTP protocol in the protocols layer too
• The backend is most likely going to consist of several elements, like:
  • Some sort of mail controller\/fetcher\/sender (probably just rename backend in the diagram)
  • An addressbook
  • A search/indexing component. I'm actually not sure if this should just be part of the mail controller
  • Probably a config reader or something. config-rs works great.

Regarding the protocols, the GUI, the config reader, etc. we should probably make interfaces to all of them for easy interchangability.

Furthermore, is the idea still to store all mails locally, operate locally and then sync with the server? I haven't looked into how this is normally done, but I guess that is the most obvious thing to do?

Any remarks?

Oh, and thanks for starting this discussion, I've been thinking about this, as we should really get on the same page before we start! 👍

[Ezbob]

There is a lot wrong with the diagram I put up. ;-) It is just to get us thinking about a super top architectural level of the client.

The backend layer has to be decomposed into important modules such as data stores, config-handlers and mail fetchers/senders, sure. Also a logging submodule would probably be nice if we where to get debugging info at some point.

I think we should keep a local cache of the mails received and sent (as well as any drafts). Maybe a regular SQL database would help us with the indexing/ and searching through mail... (not sure)

I would reckon that some uniform interfaces would be most important on the border of the layers (referring here to the original drawing), since code for specific protocols and UIs would be more or less replaceable code (or at least something we could expand on) while stuff like the mail database and controller would be more stable and less subject to change.

You're welcome. ;)