0

I am proposing that [Akonadi] design be modified such that the [pim] clients for e.g. [kmail], can revert to their old behaviour or adopt the new behaviour depending on the setup. For individual desktops, the old paradigm clients are the better option. For an enterprise setup, the akonadi repository can be setup and the PIM clients can take advantage of this.

I will try to attach a couple of documents shortly.

https://docs.google.com/folder/d/0B-uGn1gN-3JPWE1yR2JtbXkzYU0/edit

What you propose is impossible[*]. If you don't want Akonadi based apps, use a different one.
The whole idea of Akonadi is valid not only for enterprise, but for desktop as well. If you want nice email notifications, calendar views in Plasma, facebook contacts in KMail, etc. you will need Akonadi. Otherwise all the application have to do the same over and over. You have to setup them one by one, they probably need to have their own custom local cache, all this resulting in code and data duplication for ... what?
And you need to maintain e.g IMAP related code in all applications that could possibly use IMAP for communicating. Note that reusing an IMAP/POP3/whatever library won't solve all the problems, like local caching of the data. Do you want different address book for KMail and Kopete, Telepathy, etc? Probably not. So you need to share the data. You need to share the configuration options. You need to share the way to communicate with the server. Here there is something that does exactly that: Akonadi.

[*] It is impossible as all code that Akonadi duplicates was removed from KMail.

vmuppalla wrote:I am proposing that [Akonadi] design be modified such that the [pim] clients for e.g. [kmail], can revert to their old behaviour or adopt the new behaviour depending on the setup.

Parallel code paths of such magnitude would be very hard to maintain, not counting that the "old behavior" would either have to be reimplemented or a huge hack on top of the extremely complex old code base.

In any case, interestingly the document attached describes the opposite of what you posting implies, making it very likely that there is a misconception about both the previous state and the current state.

The previous state, called "old behavior" in the posting, is having huge monolithic applications which basically "own" their respective data and transfer methods.

The current state, here referred to as "new behavior", is having client which are only concerned about display and input, sharing specialiced connectors for various data sources.

Assuming that the document is not depicting the current state with some smaller inaccuracies but intends to reflect the suggested design, then the suggested design is already more or less the current design

Cheers,
_

vmuppalla: Like anda_skoa already said, what you describe IS how Akonadi works. Akonadi is NOT a storage layer, it IS that adaptor layer you described. So, rejoice, the KDE PIM team did not make the mistake the Evolution team did!

The applications are indeed a thin layer using the connectors from Akonadi to directly grab mail from gmail, hotmail etc etc

The 'old' applications from KDE3 did all the downloading (and locally caching of mail, if you wanted to) themselves, now they share that functionality through 'Akonadi', nicely separated.

As a matter of fact, there is now work going on to bring Akonadi to mail servers (in Kolab) and put it between the mail client and the Kolab server so you can use the 'connectors' to have several mail boxes etc in the one client: gmail, hotmail, etc etc.

jospoortvliet wrote:vmuppalla: Like anda_skoa already said, what you describe IS how Akonadi works. Akonadi is NOT a storage layer, it IS that adaptor layer you described. So, rejoice, the KDE PIM team did not make the mistake the Evolution team did!

The applications are indeed a thin layer using the connectors from Akonadi to directly grab mail from gmail, hotmail etc etc

The 'old' applications from KDE3 did all the downloading (and locally caching of mail, if you wanted to) themselves, now they share that functionality through 'Akonadi', nicely separated.

As a matter of fact, there is now work going on to bring Akonadi to mail servers (in Kolab) and put it between the mail client and the Kolab server so you can use the 'connectors' to have several mail boxes etc in the one client: gmail, hotmail, etc etc.

Unfortunately, Jos, I do not agree that this is the case. If you try to use kmail ( or some other PIM clients), your mail is forcibly converted (nay, 'imported') in to a local proprietary storage. True, it doesn't do that for gmail - why do that with the downloaded local mail ? Why force use of mysql and the proprietary mail converters - isn't this a run time overhead ? I understand the original idea behind that - nepomuk etc. Unfortunately, google beat everyone to it - any document stored as google doc can be searched.

In fact, they even perform 'smart' search inside binary format files. For e.g., if you uploaded hawaii vacation pictures in picasa, and search for 'beach', it will return these images, even if the photos had no caption at all ! I don't think anyone can catch up with them in this regard so why even try ?

vmuppalla wrote:If you try to use kmail ( or some other PIM clients), your mail is forcibly converted (nay, 'imported') in to a local proprietary storage.

I don't know about "some other PIM clients", but KMail uses maildir, which is basically a pretty simple directory structure holding one mail per file. That is the message as it came through the wire, in RFC822 format.
Or are you referring to MBOX files, which contain multiple messages? The messages arre still in RFC822 format, just separate by a well formatted string.

Both are rather established formats, used across a range of programs. Open Standards as far as I can tell.

Cheers,
_

anda_skoa is right: KMail does NOT convert your mail to some weird format, it uses industry standards to save your mail locally, just as it always has. Akonadi is a cache, nothing more. Read about the design and look at the architecture picture (which uses the term 'storage' where they mean a temporary storage or cache, btw): http://community.kde.org/KDE_PIM/Akonadi

And really, dude, if you're not sure about it, READ that page, READ the mailing lists and/or come to a meeting. There will be one in Osnabruck in Januari, I believe. Volker (who designed most of AKonadi) can explain it to you

now 06 november 2012, kde 4.9.3 does not have a mail reader.
This is the main fact.

eticre wrote:now 06 november 2012, kde 4.9.3 does not have a mail reader.
This is the main fact.

I don't really understand that - I'm using KMail ATM in SC 4.9.3 - it is there, it works. It's not perfect but what mail client is perfect?

jospoortvliet wrote:I don't really understand that

Maybe the comment means that the distribution in question does not package all of KDE SC.
According to the git log the KDE community produces a mail handling application since around 1997.
According to my oldest mails I am using it since 2000.

So "does not have a mail reader" most likely means it is not being vailable to that user, it certainly has been part of KDE's application portfolio for ages.

Cheers,
_

I understand that it's almost impossible to implement akonady and old way of work for KDE PIM applications but hope that akonady architecture can be changed to something scalable. Scalable in the meaning that it eats reasonable amount of resources according to use case. Less features used less resources used and less useless dependencies installed. If I read about 60 mails per week and send about 3 per week I don't want to have SQL server installed and 14 resource eating "akonady*" processes always running. Why can't akonady_imap_resource be started only during mail sync? Why there are 6 akonady_agent_launcher eating about 5Mb each and 17Mb shared? Why akonady_nepomuk_feader is running if I always keep nepomuk disabled? Why all of this processes remains alive after all PIM applications are closed?.

jospoortvliet wrote:

eticre wrote:now 06 november 2012, kde 4.9.3 does not have a mail reader.
This is the main fact.

I don't really understand that - I'm using KMail ATM in SC 4.9.3 - it is there, it works. It's not perfect but what mail client is perfect?

I'm using KMail since 2006 few month ago it was opened only when I wanted to send mails. I was reading mails through the gmail web interface since the moment I diskovered that my system becomes responsive after killing all akonady related processes (discovered about a year ago). Fortunatelly today I can have kmail running all the time (after upgrading ram from 2Gb to 8Gb somebody called akonady "thin layer" I wonder what is "thik layer" then). One can actually say that there is no mail software, only resource eating software with email client as extra feature.

VestniK wrote:I understand that it's almost impossible to implement akonady and old way of work for KDE PIM applications but hope that akonady architecture can be changed to something scalable. Scalable in the meaning that it eats reasonable amount of resources according to use case. Less features used less resources used and less useless dependencies installed. If I read about 60 mails per week and send about 3 per week I don't want to have SQL server installed and 14 resource eating "akonady*" processes always running. Why can't akonady_imap_resource be started only during mail sync? Why there are 6 akonady_agent_launcher eating about 5Mb each and 17Mb shared? Why akonady_nepomuk_feader is running if I always keep nepomuk disabled? Why all of this processes remains alive after all PIM applications are closed?.

jospoortvliet wrote:

eticre wrote:now 06 november 2012, kde 4.9.3 does not have a mail reader.
This is the main fact.

I don't really understand that - I'm using KMail ATM in SC 4.9.3 - it is there, it works. It's not perfect but what mail client is perfect?

I'm using KMail since 2006 few month ago it was opened only when I wanted to send mails. I was reading mails through the gmail web interface since the moment I diskovered that my system becomes responsive after killing all akonady related processes (discovered about a year ago). Fortunatelly today I can have kmail running all the time (after upgrading ram from 2Gb to 8Gb somebody called akonady "thin layer" I wonder what is "thik layer" then). One can actually say that there is no mail software, only resource eating software with email client as extra feature.

Part of the issue is that doing this properly simply DOES eat quite some resources. Part of the issue is that there is still place for optimization but that needs to be DONE by somebody. The reason things keep running is because they work in the background... Again, auto-shutdown for this would not be a bad idea but somebody has to implement it.

If you want to understand a bit about why this whole Akonadi thing was build, see my post here: http://lwn.net/Articles/547466/

VestniK wrote:I understand that it's almost impossible to implement akonady and old way of work for KDE PIM applications but hope that akonady architecture can be changed to something scalable.

Any specific thing in the architecture that is currently not scalable?
I mean of course it is orders of magnitude more scalable as the previous approach, but maybe you have found something even on top of that improvement?

VestniK wrote:Scalable in the meaning that it eats reasonable amount of resources according to use case. Less features used less resources used and less useless dependencies installed.

Sure, nothing in the architecture preventing that. One of the bonus results of separation of concerns

VestniK wrote:If I read about 60 mails per week and send about 3 per week I don't want to have SQL server installed and 14 resource eating "akonady*" processes always running.

Right, all possible. Not using an SQL server is even possible with the current implementation

VestniK wrote:Why can't akonady_imap_resource be started only during mail sync?

On most systems application startup can still take several seconds. Launching the resource for every request would delay each request. Offline IMAP, aka mail sync, is only one possible usage for IMAP, some users employ Online IMAP, requesting and changing data as they go.

But again, also covered by the architecture, the applications only talk to the server, how and when it talks to the resources it up to it.

VestniK wrote:Why there are 6 akonady_agent_launcher eating about 5Mb each and 17Mb shared?

That's probably your setup. The agent launcher is a generic process that can load multiple actual agents if necessary, e.g. on systems with limits on how many processes can be run by a single user.
Linux systems usually don't have a low limit on that so the more robust approach can be used and each agent is run separately.
The number of course depends on the requirements. Common setups have at least one resource for each main type of PIM data: contacts, mails and calendar, plus in a setup using mails, the mail sending facility and the mail filtering facility.

VestniK wrote:Why akonady_nepomuk_feader is running if I always keep nepomuk disabled?

Probably not implemented yet or a bug

VestniK wrote:Why all of this processes remains alive after all PIM applications are closed?.

Could be implemented. The current implementation was mostly based on experience gathered over years, which usually included things like new mail notifications, calendar reminders, addressbook integration for chat programs, etc.

Cheers,
_