[fpc-other] How do you keep up with FPC discussions?

[Graeme Geldenhuys]

On 2017-05-25 12:09, Bo Berglund wrote:
> But my observation is that email is not the best way of managing these
> things even if you *can* create some folder structure. Email clients
> evolve a lot and suddenly your old store of messages is not readable
> anymore.

I've been working on and off (more off than on these days) on a local 
project where I am rethinking emails completely. I too never delete 
emails and my archives go back nearly 15 years. It's a nightmare to find 
anything, because I used multiple email clients over the years.

So my new project splits the "email client" into two parts. The headless 
email daemon/service. This does the polling of the inbox in one or more 
mail accounts, and also does all the sorting of messages (via user 
defined filters). Messages are then stripped apart and stored in a 
Firebird database (other database servers like MySQL (G*d forgive me), 
Oracle, PostgreSQL, MS SQL Server etc) are also supported. No 
information is lost, and the original email (pristine and untouched) can 
be regenerated from all the parts.

When I say "filtering", I really mean messages are tagged. There is no 
such thing as a physical "folder" (tables) in the database. By default 
new messages will get the "new" tag assigned to them, and whatever other 
active filters are available to that account.

I then have the GUI front-end, which doesn't actually do any emailing at 
all. It is simply a client/server application (but can also be 
recompiled to be a 3-tier client via HTTP). The filters create a 
"virtual" treeview structure of your messages. Moving a message from one 
folder to another, doesn't physically move the message, it simply update 
the tag associated with that message, which then makes in appear in a 
different location in the GUI. Multiple tags can be applied to the same 
message, so you can find the message in many ways, and no duplicate 
copies of the message exists. Full-Text Searching is supported too.

Posting a new email creates a new database entry, and tagged with the 
outgoing "queued" tag. I've defined (user configurable) a 5 minute delay 
before outgoing messages are actually sent. The daemon will then pick up 
those queued messages and physically send the emails at the right time. 
Emails can also be scheduled for sending at a specific date and time of 
your choosing.

The daemon also has the ability to import existing emails from Mbox 
(MailBox) files or IMAP folders.

This opens up multiple possibilities. If you don't like the default GUI 
front end, change it or build your own, or even design a web-based 
version, or create a console version (that mimics your ELM or Alpine 
clients).

The database table structure is pretty straight forward, no DB specific 
stored procedures are used - so very portable to other database servers. 
The database communication is all done via objects and abstracted away 
using the tiOPF framework. The current GUI client also uses tiOPF to 
communicate with the database or the middle tier app server.

The project is far from complete, but whenever I have a spare moment I 
work on it further. I hope to one day unify all my email archives into a 
single database and easily searchable via the GUI frontend.

Regards,
   Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp