A tentative development of a new Pim (for KDE)

Update 2018-04 While I still think that the current version of Akonadi not work (I still use ClawsMail…), there is a new more advanced software in development Kube. I have not tried it, but it seems promising.

After the switch back to Claws Mail thanks to the again useless Kmail&Akonadi couple, I was done with KDEPim. The problem however is to find a nice Qt software to use instead of Kmail and the other KDEPim component, better if not dependent on KDE itself.
So I tried to write down some thoughts, with the idea to try to come up with some code and maybe a complete system later.

Starting point
The idea behind akonadi, as I alread said, it is not bad itself: to store all the informations in a central repository is actually a good idea but this has to work reliably, so after some pondering I come up with the idea that maybe it is possible to write a PIM (Personal Information Manager) which can work well and be simple enough, using modern tools and components, without the necessity to reinvent the wheel or rewrite something.

Architeture
Basically the PIM should be a central repository which contain all the data and information. Thus the idea is to write a service to act as a backend to store information and so on.
Since the last development, all the data trasfer between the backend and the client should be use the HTTP methods and work with JSON payloads.
Since the backend will store also all the informations (so, all the emails will be saved in a collection, all the contacts in another collection, and so on) it should make easy to write clients which basically will have only one entry point, the backend, and can focus on their specific functionalities.

To this end, some of the tools I am considering to use are:

  • NodeJs with HapiJs to have a fast and scalable server
  • MongoDb to store/search data
  • Docker to allow the possibility to run the PIM as a black box

I select MongoDb as database since, beeing a noSql db, it has not a fixed schema and so I have not to plan for everything. For example, a mail can or cannot have some tags: using a Sql db you should somewhat plan for this, either creating a table that keep a list of tag for a message or having a field in the record. Using a noSql db, the client just pass all the informations as a JSON document and the backend just store it.

Taking advantage of the async nature of NodeJs, it should be relatively simple to write the backend, also given the large ecosystem around NodeJs.