kumaran wrote:From a software architecture perspective, the Akonadi system is unnecessarily heavyweight.

How is a system designed with a core service that does nothing else than provide caching and uniform data access heavyweight?
I would tend to agree if it were doing a lot more things, but the main idea of the architecture is to not do everything in one heavyweight process but have each process do one task.

kumaran wrote:I am not convinced that a MySQL server is required to hold the PIM data.

It isn't since it doesn't hold PIM data (unless you mean the periods when it caches small parts of PIM items, e.g. mail headers).
Just wanting to make sure this isn't one of the cases of misunderstanding which lead people to falsely believe that an Akonadi setup stores PIM data in the database.

kumaran wrote:Most users simply want to keep a single address book and calendar.

There are certainly users with such PIM needs. I am not quite sure in the "most" part, because I know a lot more people that also use e-mail than I know people who only use addressbook and calendar.

But of course the people I know might be the exception.

kumaran wrote:SQLite would have been more than sufficient for this purpose.

True, for those users it might be sufficient once it works reliable, e.g. doesn't deadlock anymore.
Which is why Akonadi was designed to support multiple cache backends, one of them being SQLite.

Cheers,
_