On Wednesday 15 April 2009, jedd wrote: > So if I don't make any changes at this end, 4.3 will, when it arrives, > just work with this mbox/maildir hybrid arrangement? Short answer: yes. Long answer: probably not in the way you think about it right now. Full answer: KMail will still use its mail directory with any folder configuration you are currently using. Akonadi is, as of KDE 4.2, capable of handling maildir and gets support for mbox in 4.3. So it can handle the same data, however, since KMail is still using the data directly (scheduled to be ported by KDE 4.4), I would recommend against letting Akonadi resources access it as well. But you are free to experiement with whatever folder setup you want to use with Akonadi and an Akonadi enabled mail client such as Mailody. > > It mostly a per daemon overhead, not per database. Something used > > internally by the InnoDB backend of MySQL, can't remember the > > details. > > 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. The initial idea was to use something embedded, e.g. SQLite [1], MySQLEmbedded, however that didn't work for various reasons, e.g. MySQLEmbedded not supporting InnoDB (needed for its transaction support). The choice of starting a dedicated mysqld is basically the closest thing, e.g. not requiring any user configuration. Not all users would have the knowledge to correct answer debconf questions and not all operating system vendors have such a concept. Of course any operating system vendor is free to ship exactly such a default confguration, any system admin can do the same. > > I am not aware of any way Akonadiconsole could display which apps are > > not using Akonadi. > > My mistake. I should have gone back and checked the actual UI. > > System Settings | Advanced | Akonadi Config > -- std.ics and std.vcf both report as 'no file selected'. Not good, sounds like a bug in the migrator or "first-run" utility :( > Contacts and calendar information are both present in kontact, > so I'm not too worried. I've been meaning to experiment with > the Sys-Settings (as above) and telling Akonadi that to use my > std.ics and std.vcf . Would this be a sensible thing to do, or > a dangerous and unpleasant thing to mess with at this stage? Yes, this should not be a problem. Basically even required for people using KPilot, since it is already fully ported to Akonadi. > The more I think about it, the more I think you guys should > consider forcing Akonadi users to have a standard MySQL > instance running and just plug into it using Debian tools. I think > from a user's perspective they'll have the same performance > metrics, but their disk usage and general 'transparency of > installation' will be much better. As I tried to explain above, this is something we can't do that easily on our level. Could be done at distribution level, but would probably still be quite some effort. > I know you guys have probably beaten around this subject for > a while .. so apologies if I'm bringing up already resolved issues. No problem, it is always good to get some feedback, there is always something we didn't hear about yet. Cheers, Kevin [1] Just recently someone really motivated put quite some work into getting SQLite work as a backend. He managed to get the database creation working, however there are still problems with concurrent access, like getting into deadlocks, etc. I think he finally gave up for now, though his work might come in handy once a newer version of SQLite becomes available which might have fixed the concurrency issues.
Attachment:
signature.asc
Description: This is a digitally signed message part.