Besides the fact that using SQL server to store ~1000 PIM records is wasting of all kind of resources (are you ecology friendly?), MySQL is absolutely unacceptable for my system.

Is it possible to disable akonadi completely (preferred) or is it possible to build akonadi without mysql?

I believe Akonadi is currently only a dependency for KDEPIM applications and some Akonadi related data engines in Workspace. It however might be a direct dependency for kdepimlibs which is required for building KDE.

It therefore may be possible, but I doubt it. Akonadi doesn't have to be running all the time however. As long as you don't use Kopete or KMail then it will probably never start automatically.

i disabled akonadi in systemsettings and kmail's imap account works fine

It is a build time dependency for kdepimlibs and a runtime dependency for applications using it (obviously).

Which at this time are extragear application Mailody and KDEPIM applications KPilot and KJots.
It might be used optionally by other applications through the use of compatibility plugins, however they are not enabled by default.

As for using MySQL, Akonadi Server does not use it for storing PIM records, only for keeping track of PIM data.
PIM data is stored in usual places, e.g. local files or respective servers (e.g. mails on an IMAP server). Depending on cache settings some data might also be temporarily available in the database.

Actually it is not using MySQL but a rather abstract database interface. MySQL is the default backend because it is known to work reliably. There have been reports that people are using it successfully with PostgreSQL and some developers are trying to work around SQLite's limitations to get it supported as wel..

Cheers,
_

anda_skoa. Thanks a lot for constructive answer.

I used to Kopete but I could disable KDE pim as a whole. Unfrotunately akonadi is a part of required kdesupport package but not kdepim so I have to build akonadi and all it's dependencies (like boost) ever if I have no plans to use it. It's bad development style and have to be fixed asap.

Also I flicked through akonadi code and can't understand what prevent developers from using innodb directly, without SQL layer.

PS: Hope KDE team will not add Oracle or DB2 to list of required software for KDE 5

yrat wrote:I used to Kopete but I could disable KDE pim as a whole.

Neither kopete not most of KDE PIM use Akonadi right now.
KAddressBook almost made it for KDE 4.3, though.

yrat wrote:Unfrotunately akonadi is a part of required kdesupport package but not kdepim...

That is the cross-desktop, i.e. non-KDE, part, the Akonadi server and its helper process Akonadi control.
KDE's Akonadi client library, libakonadi-kde, has a build time dependency on a library shared with the server, which could probably be built and installed stand-alone.
See kdesupport/akonadi/libs

yrat wrote:... so I have to build akonadi and all it's dependencies (like boost) ever if I have no plans to use it. It's bad development style and have to be fixed asap.

The library shared between server and client code can probably be built and installed separately, see above.

yrat wrote:Also I flicked through akonadi code and can't understand what prevent developers from using innodb directly, without SQL layer.

Interesting approach.
The questions are whether this would be more complex than just doing SQL and whether this would allow things like shared DB server instances.

I am also not quite sure the engine is available as a separate package or if it is part of the server package.
If I remember correctly there have even been packaging problems with the MySQL/Embedded library/plugin, which was AFAIK the initially targetted DB access method.

yrat wrote:PS: Hope KDE team will not add Oracle or DB2 to list of required software for KDE 5

Unlikely since at least Oracle is non-free software.
Given further progress on the database front, it is more likely that the dependency can be specified less strictly, i.e. allowing a tested one out of many choice.

Cheers,
_

anda_skoa wrote:Neither kopete not most of KDE PIM use Akonadi right now.
KAddressBook almost made it for KDE 4.3, though.
...
That is the cross-desktop, i.e. non-KDE, part, the Akonadi server and its helper process Akonadi control.

Sounds promising! It's enough to at least start migration. Let you know what happens finally

anda_skoa wrote:

yrat wrote:Also I flicked through akonadi code and can't understand what prevent developers from using innodb directly, without SQL layer.

Interesting approach.
The questions are whether this would be more complex than just doing SQL and whether this would allow things like shared DB server instances.

see:
http://www.innodb.com/doc/embedded_innodb-1.0/
It's direct competitor of SQLITE and contains it's own simplified SQL layer so code change should be minimal.
Also they can use BerkeleyDB - it's require more programming but IMHO it's the best approach.

Shared DB instance for PIM data is a separate topic. Technically DBus is enough to give shared access to the same data. However, How they plan to manage access of different users to that shared data?

I don't do much investigation of akonadi code, but it looks like they aren't concerned much about security. If a hoster of my shell account would have a shared mysql instance holding everybody's PIM data (according to akonadi team recommendations) simple brute-force attack gives me access to it shortly.

yrat wrote:

anda_skoa wrote:

yrat wrote:Also I flicked through akonadi code and can't understand what prevent developers from using innodb directly, without SQL layer.

Interesting approach.
The questions are whether this would be more complex than just doing SQL and whether this would allow things like shared DB server instances.

see:
http://www.innodb.com/doc/embedded_innodb-1.0/
It's direct competitor of SQLITE and contains it's own simplified SQL layer so code change should be minimal.

Would be interesting to know how difficult a QSQL driver for that would be.

yrat wrote:Also they can use BerkeleyDB - it's require more programming but IMHO it's the best approach.

Definitely worth investigating.

yrat wrote:Shared DB instance for PIM data is a separate topic.

True. I meant that any abstraction should probably allow that usage scenario.

yrat wrote:Technically DBus is enough to give shared access to the same data.

Not really.
First there is no database server available which is capable of doing D-Bus (on the system bus) and second transferring huge amounts of data through D-Bus might not be viable either (limited message lengths, etc).

There are reasons why it is not even used in the scenario of a user local database.

yrat wrote:However, How they plan to manage access of different users to that shared data?

I believe that database servers have facilities to restrict access to databases, e.g. allowing each user to access his/her own database and denying access anyone else.

yrat wrote:If a hoster of my shell account would have a shared mysql instance holding everybody's PIM data (according to akonadi team recommendations) simple brute-force attack gives me access to it shortly.

Can you point to the recommendation?
Because by default the database is user local, thus having the same level of access security as the files which hold the actual data.
I.e. if an attacker can gain access to the user's login credentials, they can easily read the files. e.g. vcard or ical files, directly.

Cheers,
_

If you have MySQL connected to UNIX socket and this socket is 0600 everything is OK - but it's terrible inefficient if you have multiuser system.
If you setup shared MySQL server to hold PIM data as for recommendation in akonadi FAQ some issues come to light.

I believe that database servers have facilities to restrict access to databases, e.g. allowing each user to access his/her own database and denying access anyone else.

1. You have to store encrypted i.e. reversible password on local disk rather than just a hash of it.

2. You have either sync mysql password with system account (it's dangerous) or maintain separate login/password pair with it's own expiration and change policy.

3. As far as you have local UNIX socket with 0660, everybody is free to silently torture your shared database so admin have to setup audit and care a lot about security patches.

etc ...

I'm not sure it's the level of complexity you expect for KDE PIM. So I guess akonadi developers should think about effective local storage rather than rely on shared DB server as a multiuser solution.

yrat wrote:If you have MySQL connected to UNIX socket and this socket is 0600 everything is OK

Which is the default setup AFAIK.

yrat wrote:but it's terrible inefficient if you have multiuser system.

Not sure about the "terrible" part, but it might be more efficient file system space wise to have transaction tables only once.

yrat wrote:If you setup shared MySQL server to hold PIM data as for recommendation in akonadi FAQ some issues come to light.

Puzzled by your earlier mentioning of this I checked the FAQ but couldn't find any such recommendation.
The fact that the default setup does use a user local database seems to contradict that.

yrat wrote:1. You have to store encrypted i.e. reversible password on local disk rather than just a hash of it.

True, but this is almost certainly also the case for authentication data needed to access of remote data sources such as IMAP servers.

yrat wrote:2. You have either sync mysql password with system account (it's dangerous) or maintain separate login/password pair with it's own expiration and change policy.

Ah, didn't know this was dangerous. Actually I would have expected that to be the default setup for any system service, i.e. single sign on.

Or is this a problem for MySQL and other services implement better behavior?

yrat wrote:3. As far as you have local UNIX socket with 0660, everybody is free to silently torture your shared database so admin have to setup audit and care a lot about security patches.

I would have expected that this is just a variant of point 2.
Does this mean MySQL is only capable of user access control when being used through TCP/IP?

yrat wrote:I'm not sure it's the level of complexity you expect for KDE PIM.

Which is probably one of the reasons it is not the default setup as shipped by Akonadi.

yrat wrote:So I guess akonadi developers should think about effective local storage rather than rely on shared DB server as a multiuser solution.

I am pretty sure one of the embedded database engines will at some point be capable of delivering the necessary feature set, e.g. SQLite working properly in a multithreaded environment, mysql/embedded understanding transactions, etc.

Using a locally running database server instance is quite certainly a an intermediate solution until something like that happens.

Cheers,
_