Page MenuHomePhabricator

Email
Updated 931 Days AgoPublic

IMPORTANT: Page is heavy WIP. I put here parts of my thoughts. Will sure be unclear at first... will improve with the time.

Email aims at being a decent/awesome email client, written in EFL of course, with the best ideas in the world!

NOTE: This document is an RFC (Request For Comment) for now. Nothing works yet :-) Please feel free to update this document to propose any ideas, architectural designs, ...

Email's repository is located at https://git.enlightenment.org/devs/jayji/email.git/.

About the name (RFC)

Email starts with an E, and seems a cool name for an email client. Better ideas are welcomed though.

Architectural Design (RFC)

Email would be split in three objects:

  • bin/email, the main executable, which role is to do orchestration. No fancy display, no fancy editing. Just an entry point that will take input commands (via getopt or maybe an internal shell);
  • modules/*/*/*.so, loadable modules that will provide functionalities (more on this later);
  • lib/libemail.so, a library that factorizes utilities between the main executable and modules.

The interest of modules would be that any developer could create any, to:

  • intercept actions (add runtime callbacks). E.g. do something special when receiving an email from a specific person;
  • support alternatives;
  • make lighter components, easier to test independantly.

Modules (RFC)

A module can be seen as a plug-in. It provides run-time functionalities that can be loaded/unloaded
and provided by users.

Modules will of course use Eina_Module for dynamic loading.
They can be seen, from a developer perspective as classes that inherit from a well-defined interface, and are loaded at run-time.

To better understand, here is an example implemented as a proof of concept (POC):

Imessage modules (POC)

The email framework transits text files that respect the Internet Message Format (IMF) - RFC 5322.
It may seem odd to have IMF handled as an external module since it will be requires no matter what... however this may tackle future
formats in the future or make life easier for people wanted to implement a subset of the IMF (because they want to, don't ask me why).
It also serves as an illustrative POC.

When one want to write an email, one will actually edit text following the IMF, then pass it to a magic black box that will send it.
The magic is SMTP, but it does not have to be!!! It can be anything by design, as long as it is implemented of course...

Here is pseudocode:

Email_Imessage *msg = email_imessage_new("IMF", "Blah blah blah, this is my email...");
msg.check(); // Syntax error/warning according to the RFC?
msg.check(GRAMMAR); // Did I spelled correcty?

Email.Module is an abstract class that will serve as a basis for all other plugins.

Graphics, graphics, graphics (RFC)

Graphics would be provided through modules, because (mostly) everything will be a plugin...
A "GUI" module would fork() and spawn its own elementary process, or ecore_exe_[pipe_]run().

Last Author
jayji
Last Edited
May 23 2016, 1:49 PM
Projects
None
Subscribers
jayji