mhl wrote:what in my opinion sounds quite funny because what is KMail without adressbook functionality?

This really depends on each person's workflow, e.g. whether the person is often the source of new emails or whether the majority of mails are replies, etc.

Anyways, the whole point was to give some insight into why there seem to be conflicting statements on Akonadi usage in KMail.

So this is a kmail bug and no Akonadi bug! Or even more precisely: This is (was) a bug of the interface between KMail and Akonadi!

Exactly

From the users perspective it does not make any difference anyway.

I agree, but I felt it to be necessary to provide some detailed information in what actually happened, even if it will just help people to look for workarounds at the right place.
(the error report lead several people to believe they had to change certain environment variables, which could just make things worse).

Cheers,
_

Thanks, Anda, very helpful! And this proofs, that developers and users can talk to each other!

For sure what I wrote in the title was not pure diplomacy!

But you know, that users rule the IT world!

Regards, Martin

Anyway, Anda's answer helps with this Akonadi question but it does not solve all problems that I tried to state - they go deeper!

Regards, Martin

anda_skoa wrote:When people write it does not use Akonadi yet, they usually mean that it does not use Akonadi for its main data (emails) yet,

You're speaking as a developer here (with the development roadmap in mind). That explanation does not help users very much. From a user point of view, KMail does use Akonadi. "Where? I don't know. But I cannot use KMail because of it".

Hi dpalacio,

dpalacio wrote:

anda_skoa wrote:When people write it does not use Akonadi yet, they usually mean that it does not use Akonadi for its main data (emails) yet,

You're speaking as a developer here (with the development roadmap in mind). That explanation does not help users very much.

I think Anda's explanation is ok and he already agreed!

dpalacio wrote:From a user point of view, KMail does use Akonadi. "Where? I don't know. But I cannot use KMail because of it".

For sure you are right and it is necessary to state this as well! This shows us, that in a modular system not only the single part is what we have to look at but the whole must work. Let me say it different: Quality management must focus on the interaction between the different parts of KDE - who takes the responsibility for that?

Regards, Martin

anda_skoa wrote:

From the users perspective it does not make any difference anyway.

I agree, but I felt it to be necessary to provide some detailed information in what actually happened, even if it will just help people to look for workarounds at the right place.
(the error report lead several people to believe they had to change certain environment variables, which could just make things worse).

Cheers,
_

Actually, it seems like the question is "Do kmail and akonadi each have a complete and defined set of user-recognizable functionality and utility separately from each other?".

If the answer is "Yes", then neither is required of the other and each can operate and be distributed independently of the other.

If the answer is "No", they are tightly coupled, each is probably not cohesive, and at least one is then incapable of independent action.

If the answer is "It depends", then they belong to some indeterminate set and are improperly defined, at least at this point in time.

We may have found the definitive case of "definite maybe"

Akonadi is the SPOF of KDE PIM. I wonder how that will work out.

Hey

samhain wrote:Akonadi is the SPOF of KDE PIM. I wonder how that will work out.

Your statement does not help! I know that I choose this header but I never aimed to just state that it does not work! It does not work yet correctly and the big fault was to simply eliminate functionality. But I have no doubt that this architectural element does make sense! So why should we discuss this?

I discuss quality management and release policy, so come on and switch to a different view!

jglen490 wrote:Actually, it seems like the question is "Do kmail and akonadi each have a complete and defined set of user-recognizable functionality and utility separately from each other?".

Right.

I guess it depends on the usage pattern.
When exclusively KMail, Akonadi will look like being part of KMail or actually being invisible as a separate entity.

When using something else in addition to KMail, e.g. a new mail notification applet, mail related desktop widgets and so on, it will be relatively obvious that some functionality is not dependent on KMail but handled by something else.

Conceptually it is like a virtual file system, it is there independent of whether a file manager or any other application is using it.
If a user only every interacts with files through a file manager, it could seem that the file system functionality is actually part of the file manager.
Once other applications expose some parts of the same functionality, e.g. through a file open dialog, it will become noticable as a separate entity.

jglen490 wrote:If the answer is "Yes", then neither is required of the other and each can operate and be distributed independently of the other.

If the answer is "No", they are tightly coupled, each is probably not cohesive, and at least one is then incapable of independent action.

If the answer is "It depends", then they belong to some indeterminate set and are improperly defined, at least at this point in time.

We may have found the definitive case of "definite maybe"

It isn't a yes or no kind of question, we are talking about layers here.
Lower layers provide services to upper layers, usually just to the next upper layer. This makes the lower layer usually independent of the next upper layer, but makes this upper layer depend on the lower layer (or an equivalent implementation of it).

I.e. applications depending on operation system services being present but operation system service not depending on any applications using them.
In this case Akonadi does not depend on any application using it, but applications depend on it or an equivalent being present.

Cheers,
_

mhl wrote:Hey

samhain wrote:Akonadi is the SPOF of KDE PIM. I wonder how that will work out.

Your statement does not help! I know that I choose this header but I never aimed to just state that it does not work! It does not work yet correctly and the big fault was to simply eliminate functionality. But I have no doubt that this architectural element does make sense! So why should we discuss this?

I discuss quality management and release policy, so come on and switch to a different view!

You didn't get me. mysql for akonadi is configured in ~/.local/share/akonadi/mysql.conf You can tweak it to your needs, just look at http://dev.mysql.com/doc/refman/4.1/en/ ... eters.html for performance hints. Do something odd and you have problems. How can innodb be handled by backups? Are there any provision? At least I dont know of anything built in KDE now. There's the SPOF that bites all akonadi-dependend programs.

First, I would like to thank the devs on KDE. The work they have done on version 4 is nothing short of amazing, and it baffles me that anyone would want to use another DE. This is my first post, although I have contributed before.

That being said...Akonadi needs to go, or at least be an option. I just upgraded to 4.4, only to discover my address book inside Kontact being unusable. And I know Kaddressbook is only the beginning...Kmail, etc is soon to follow.

I just want a mail program. The idea behind both Akonadi and Nepomuk is awesome in theory for the business world, but useless to the average geek who uses KDE on his/her desktop. If any of the devs are reading this, please - just tell me how much to make for a donation, I'll do it. Just get rid of Akonadi in Kontact. Or at least give us an option not to use it. I'm probably going to have to start using Thunderbird now.

Or let me know what I can do to help.

Hey Tuxman!

Tuxman3458 wrote:I just want a mail program. The idea behind both Akonadi and Nepomuk is awesome in theory for the business world, but useless to the average geek who uses KDE on his/her desktop.

correct! That is something the group of developers and (non existing?) overall coordinators / release managers have to learn: They should never ever release a new technology that

a. still is beta,
b. is not correctly integrated and
c. not correctly documented

In addition to c. That means: Each user should at the moment of upgrading the system to use Akonadi, etc. be informed about what he will have to do to make this work correctly or (much better) a wizard should be started that allows the user to automatically reconfigure the system depending to users decicions.

If any of the devs are reading this, please - just tell me how much to make for a donation, I'll do it. Just get rid of Akonadi in Kontact. Or at least give us an option not to use it. I'm probably going to have to start using Thunderbird now.

Or let me know what I can do to help.

I was in a similar situation as you are. I had to write bug reports that did not help because there are too many and to "google" and at least I found out the following:

1. You have to define new the correct Akonadi-Ressources you will need, e.g. the addressbook component. -> start any of these akonadi scripts but not the "console". Funny why the console is a developers tool and funny that especially this step, to tell you which program to use, is so difficult.

2. You have to tell the system (=KDE) to use these ressources. -> KDE control center -> ressources -> add the ressources you will need.

E.g. in the situation of kaddressbook you define new akonadi-addressbooks (why are they "new"?) and convert your old addressbooks into new "akonadi-ones", a typical step for the wizard!!! Very nice step because you as a user will have to know what the technical type of your old addressbook is and where it is located - things that users normally are not interested in!

Then you can tell KDE to use these ressources. In this step, e.g. you can define that kmail can look in either the old addressbook file and the new one. As you can imagine, this is only a workaround and now you will have two addressbooks, the old and the new one. I currently cannot describe how to backup, convert and eliminate the old one. Why? I get the feeling that noone has a concept about what would be a good way and anyway it might be dangerous to through away the old addressbook file becaus the akonadi one will not work correctly, yet.

Well I at least came to the point where I have a converted addressbook and I can use both, the old one and the new one at the same time, what in fact is an advantage of akonadi!

I hope this helps! At least my failure situation now is a bit better than before but I myself still have problems with akonadi.

Regards, Martin

Tuxman3458 wrote:That being said...Akonadi needs to go, or at least be an option. I just upgraded to 4.4, only to discover my address book inside Kontact being unusable.

Can you describe that a bit more detailed? I am using KAddressBook stand-alone (i.e. I am usually not running Kontact) and it works fine.

Tuxman3458 wrote:And I know Kaddressbook is only the beginning...Kmail, etc is soon to follow.

Correct. KMail is actually the component that profits most of the new data access technology as itself becomes leaner and easier to maintain.
So calleed "Separation of concerns".

Tuxman3458 wrote:I just want a mail program.

Exactly!
Right now KMail needs to be a lot more, e.g. an offline cache, IMAP helper for address book and calendar, etc.

KMail2 can be just the awesome email program that it is.
Its developers can concentrate on mail specific issues and features.
Users of other KDE PIM components with different email needs can use a different email client without losing functionality.

Tuxman3458 wrote:The idea behind both Akonadi and Nepomuk is awesome in theory for the business world, but useless to the average geek who uses KDE on his/her desktop.

Useless in which sense?

My guess would have been that a lot of users, especially the average geek, are in a situation like this:
- using a computer that is not permanentely online, e.g. a laptop during travel
- having email on an IMAP server so it can also be accessed from e.g. a web interface
- still wanting to have access to already fetched mails during travel

Of course I am kind of biased by my own situation, but a know a couple of people being in the same. Maybe usage of laptops and IMAP are less common in other parts of the world.

Tuxman3458 wrote:If any of the devs are reading this, please - just tell me how much to make for a donation, I'll do it. Just get rid of Akonadi in Kontact.

On a technical level, applications are using a specific library to access data which in turn talks to the Akonadi server.
So, again technically, it would be possible to create a new library with the same interface but talk to a different backend or even make the library implement all backend functionality.

Practically, I am not aware of any developers outside of KDE PIM which would be available for this. But of course it can't hurt to look for those, after all there are several thousands of capable people out there and some of them might be looking for something to work on.

Cheers,
_

I was in a similar situation as you are. I had to write bug reports that did not help because there are too many and to "google" and at least I found out the following:

1. You have to define new the correct Akonadi-Ressources you will need, e.g. the addressbook component. -> start any of these akonadi scripts but not the "console". Funny why the console is a developers tool and funny that especially this step, to tell you which program to use, is so difficult.

2. You have to tell the system (=KDE) to use these ressources. -> KDE control center -> ressources -> add the ressources you will need.

E.g. in the situation of kaddressbook you define new akonadi-addressbooks (why are they "new"?) and convert your old addressbooks into new "akonadi-ones", a typical step for the wizard!!! Very nice step because you as a user will have to know what the technical type of your old addressbook is and where it is located - things that users normally are not interested in!

Then you can tell KDE to use these ressources. In this step, e.g. you can define that kmail can look in either the old addressbook file and the new one. As you can imagine, this is only a workaround and now you will have two addressbooks, the old and the new one. I currently cannot describe how to backup, convert and eliminate the old one. Why? I get the feeling that noone has a concept about what would be a good way and anyway it might be dangerous to through away the old addressbook file becaus the akonadi one will not work correctly, yet.

Well I at least came to the point where I have a converted addressbook and I can use both, the old one and the new one at the same time, what in fact is an advantage of akonadi!

I hope this helps! At least my failure situation now is a bit better than before but I myself still have problems with akonadi.

Regards, Martin

Martin, thanks for your reply.

This is an interesting concept, but in the end it should be unnecessary. I mean how many tens of thousands of mail messages, or thousands of contacts would I need before Akonadi became a real advantage? The binary search on the 4.0-4.3 KMAIL worked great for me.

I agree, that trying to eliminate an old address book tied to Akonadi altogether would probably be dangerous. Plus, with that workaround, we would need to do the same thing once mail, calendar, etc is integrated into Akonadi [puke!]...

I am probably just going to remove PIM + akonadi from my system, and start using Thunderbird. Hopefully the KDE devs will come to their senses, and realize that - while cool, such a sophisticated backend is something that few KDE users either want or care about. This seems to be a solution for a problem which nobody had.

Hi,

I do think that the situation is not funny for users or/and administrators that care about users and I wonder if after "dekades of structured and modular software development" developers will learn that the best idea will not fit if users are not helped to get it run.

But...

Tuxman3458 wrote:I am probably just going to remove PIM + akonadi from my system, and start using Thunderbird.

.. I really wonder why you should react like that. Is this the only problem/bug you have with PIM? If there were serious more, I would understand but if the addressbook is the only one and you did not use categories before there should be a workaround so that you could keep on using KDE PIM.

I use Thunderbird when having to boot Windows and I really cannot say I prefer this. KMail and PIM has a lot of advantages compared to Thunderbird and you would have to start from the beginning anyway!

Regards, Martin