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 _______________________________________________ fpc-other maillist - fpc-other@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other
