server: http://websvn.kde.org/trunk/kdesupport/akonadi/ (depends on Qt)
client: http://websvn.kde.org/trunk/KDE/kdepimlibs/akonadi/ (depends on Qt and KDE libs)

Let’s also note that Akonadi’s design is epic fail. Akonadi is basically the same exact thing as Evolution-Data-Server except that instead of offering decent client APIs (using DBus), it offers everything via IMAP - ical messages are in a Calendar folder, vcard messages are in a Addressbook folder, etc. This is the most retarded thing ever conceived. IMAP was not designed to serve data like this efficiently… and what’s worse is that neither GNOME nor KDE have even a half-way decent IMAP client implementation.

If the purpose of Akonadi is for concurrent access to messages, calendar data and vcards as MIME objects, a better design would have simply been to agree on a Maildir-like directory of messages on the local filesystem instead.

Even that, imho, would not be ideal however.

A better approach would be to agree to a specific Maildir location for mail and design similar concurrent access directory layouts for vcard and ical files and to agree to those locations as well.

Think about it - if the groupware clients are going to have to all implement the most complex mail access protocol known to man (IMAP) and they’re still going to have to implement a MIME parser, it’s not much more effort to talk to the real IMAP accounts themselves, is it? So what’s the point of talking to a daemon process using the same protocol they’d be using to talk to the server directly?

Akonadi is also inefficient by design because it forces 2 copies of the current message to be in memory (one in the akonadi server, one in the client), not to mention at least a third copy in memory for the renderer.

(KDE’s libmime++ parses entire MIME messages into RAM and iirc, so does Evolution’s).

I’m not a huge fan of Evolution, but the developers got at least 1 thing right: they didn’t make the retarded decision to make Evolution-Data-Server into a mail server.

IRC Channel #akonadi on freenode network

(Unless of course you _didn’t_ know that. Then I’d be disappointed. But even being outside the development process, that seems like an incredibly obvious moronic accusation.)

What moron would deliberately link a PIM-framework to an arbitrary GUI toolkit that the developers _knew _ ahead of time that half of the Free Software community doesn’t even want to touch, because it gives them the “heebie-jeebies”?

And _then_ propose it be a desktop-agnostic FDO standard?

Really, you’d hope you guys would be past non-starter criticism like this by now. Give the KDE guys some credit. You may not agree with their implementation, you may be jaded with how the desktop-cooperation ecosystem can still seem a mostly hypocritical minefield, but I doubt their design methods are inherently stupid/malicious/without-any-intelligent-thought-whatsoever, as that statement seemed to imply.

(Unless of course they _did_ do all that. Then I’d be disappointed. But even being outside the development process, that seems like an incredibly obvious moronic accusation.)

@Zeeshan Ali: that’s bullshit; Qt has been Free Software for a long time now (9+ years); it just went GPL->LGPL

second, i understand it would take a lot more work to get Evolution working with Akonadi. no disagreement there as it’s an obviously true statement.

what would make *sense* would b start looking at how to solve these problems properly by working on things like EvoAkonadi, and then you get things like what you just spent your time on for free.

however, by continuing to invest in the here-and-now implementation the end point of that effort continues to be delayed ever further.

what really pricked my ears up was the bit about “you could write an email client front end with it”, and if we’re all honest with ech other it’s pretty evident what the end game there is likely to turn to be.

we’ll have two incompatible solutions for no real purpose, diminishing the user experience (”why doesn’t FooCal work with BarMail? why does CoolTimeWidget only work with certain PIM apps? “) and dividing up our sparse resources in the PIM world.

it’s not an interesting or overly sexy area to work in, nor a layer where innovation is exacty the name of the game. it’s the right place to work together rather than ignore each other.

at LCA the other year, a GNOME developer gave a lightening talk during the gnome mini-conf (which i attended =) about considering using Akonadi. the Akonadi people were trying very hard to reach out to others, even offering up one of their GSoC slots to someone willing to write a gobject based client lib for Akonadi. i was hopeful.

since, though, i don’t see a lot of interest or attention being paid. i do see people reinventing wheels and fd.o saying “no” to hosting akonadi server dev due to this.

another end game is just to work at making applications that insist on their own world view irrelevent to the broader community. that would be hugely unfortunate and not a great way to service the userbase in the short term, but would at least get us to a useful long term solution.

For Evolution to start using Akonadi a lot more would have to happen. I don’t think that will happen soon enough. Nonetheless would Akonadi still need an API like this even if Evolution would…

i know in our project we’ve worked damn hard to get rid of this counterproductive pattern of behviour, and it’s paid off rather nicely.

now if we could get a decent % of the rest of the F/OSS desktop world thinking similarly, we might all just have a chance at being mildly efficient and delivering user experiences that Don’t Suck(tm).

yes, i’m frustrated. yes, this is dissapointing. yes, i don’t want the next five years to be a repeat of the last five years.

http://svn.gnome.org/viewvc/tracker/trunk/data/dbus/tracker-search.xml?view=markup

method Query is probably what you are looking for. Service would be Mail or EvolutionMail (would need to check), and you could either crarft a query with the query condition (if you only search certain fields), or just use the search_text if you want full text search over all mail fields and content.

Anyway, things will improve dramatically from 0.7 onwards.

Thanks for rocking :o)
Anders