What you really want to do is create a view which matches the current display crieteria (e.g. folder + search + sort - search is vital), and then be able to access that by rows. But then you have to somehow do threading too, which a normal db won't do, and embedded db's probably wont do views either. But all this disk-based, transaction-safe stuff is much slower then just loading it into memory ...
They've got different priorities anyway, its a commercial product that needs to care more about existing customers than doing anything interesting ...
Hi Till - i'll just drop the reply in the same message.
> Having attempted various ways of implementing on-disk and in-memory
> indexing, the last and current being mmap'd binary on-disk structures
> (with a lovely collection of data integrity, robustness and performance
> issues, (NFS, anyone?)), and having long battled huge memory footprints
> in our applications, we (the KDEPIM developers) have decided that a
> database approach to the indexing (and the caching) problem is probably
> our best bet.
Doing disk-based things is just hard, or i always found it that way - having
to worry about every fail case and recovering, performance, etc. Thats
what middle-ware is for, the hard bits :)
> I've talked to a few of the evolution hackers in Bangalore about this at
, when it was still a wild idea in the back of my mind, but
> it has since come to a state where the initial implementation is
> delivering stuff and most of the main pieces are in place. This would
> be an ideal time for any interested party to have a closer look, find
If it's just using IMAP, how is it different from say, HULA or some other
> In short, this discussion reminds me a lot of similar ones we had over
> in K-town which eventually led to Akonadi, so I couldn't resist to
> pitch it to you a bit. My apologies for hijacking the thread. If you
> have more concrete questions as to the kinds of problems we are facing
> with memory mapped index files, feel free to ask in PM or on
> evolution-hackers, which I'm subscribed to.
Yeah we had these discussions before when I was still working there.
Always hamstrung by the need to support a lumbering application, and
even some conflicting ideas,
e.g. there's no reason the addressbook
data couldn't have just been a camelfolder with a different item type,
but, well, it was already written as a corba service.
I'm not sure i'd go with an IMAP layer myself, but I suppose it
depends on what problem you're solving. I guess as far as protocols
go it isn't really that complex at the heart of it. Most of the
problems with it are dealing with in-compatabilities and
unknown-in-advance extension support and bugs.
Well, for example, I was looking at this IDL for 'message' services:http://users.on.net/~notzed/src/Evolution-DataServer-Mail.idl
e.g. look at Folder at the bottom. That basically does everything you
can do with CamelFolder, but is an awful lot simpler, and much easier
to implement server-side. i.e. supports searching, retrieving, and
modifying meta-data on messages. It could even support non-mail
Passing back a stream for the message content lets you do things
like retrieving ranges (pipelined) from an imap service, so you
can still multiplex the connection, so you don't end up hogging it
for large messages in a multi-threaded environment. In a much easier
way than partitally retreiving compound objects in the way
camel-imap does. Sure, you can't 'skip this attachment' - but we don't
anyway, since you either convert it to an icon, or snoop its content
in the client most of the time (see Philip, complexity isn't always
warranted even if it seems the right choice on the face of it :).
(I'm not suggesting this IDL is anything other than an idea I had
a long time ago. It is also too simple if you wanted to do remote
sorting/threading, and the like).