On Wednesday 15 April 2009, Michael Schuerig wrote: > On Wednesday 15 April 2009, jedd wrote: > > Fairy nuff. My gut feel is that we'd be better off making people > > run the MySQL database properly - just make it a dependency, and use > > debconf stuff to set up the database per user. If we're committed to > > having a MySQL instance to run Akonadi, then I can't see any benefit > > (and lots of problems) in running a dedicated Akonadi-MySQL daemon. > > MySQL tends to be pretty light on the CPU while it's idle, but it > > sure does like to eat up memory. And, as discussed, disk too. > > I can't help but wonder whether Akonadi and its required infrastructure > is much use to the average user. More specifically, I have a nagging > suspicion that the KDEPIM folks are running away trying to make KDE > enterprise ready with ever more involved schemes for data management, > while at the same time presumably most KDE users don't have a need for > groupware and data exchange features. Yes, pushing Linux/KDE into the > enterprise is worthwhile, but at the same time, people who don't use the > requisite features should not have to suffer for it. It will actually take a while until this hits the enterprise customers. However, most of the features are also interesting and even important for private use. For example capability to have certain data locally available when being disconnected, reliably sharing data between applications (only one process writes to a specific file based location), locally caching data stored on a server, etc. > More to the case in point, I feel decidedly squeamish about putting > mailboxes and other valuable data into MySQL. Right, however this is not what we see here. The database is used as a cache for data and only used for temporary storage if the actual data storage is not available. For example if you have an IMAP resource it can be told to always keep the envelop cached in the database, so you can do fast listings even on a slow connection (or even when there is no connection at all). Or you want to be able to apply changes to a serverbased calendar even if you are currently not connected. In such a case the data is temporarily stored in the database and sent to the remote location once it becomes available again (when the Akonadi resource handling it indicates it is switched from Offline to Online). Think about Akonadi as a kind of proxy for PIM data. It makes access fast, allows access to content currently not available directly but the canonical source of content is still where it is without the proxy. Cheers, Kevin
Attachment:
signature.asc
Description: This is a digitally signed message part.