RE: Last version of the new summary storage engine

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2007-12-11 at 00:23 +0200, Dirk-Jan Binnema nokia com wrote:
> 
> > > 2) size should also be a uint32_t, since otherwise on 64-bit  
> > > platforms you'll have a 64-bit size, there, which isn't needed.
> > 
> > Right. Unless you want to support terrabyte-sized E-mails of course. 
> 
> Also - it would be good to keep the summary format the same on
> both 32/64 platforms (and even different-endian), so I can maintain
> one ~/.tinymail no matter what I use (this is a real issue on
> AMD64, where you can run 32-bit and 64 programs at the same time).

This can easily be made possible btw. Just about being a bit careful
here and there and testing it.

> BTW, wild other idea, what about using, say, SQLite for storing the
> summary information? I think that could save us from a lot of
> error-prone lowlevel hacking (think about row-level locking)
> and make debugging easier. I am not sure about the memory/speed 
> tradeoffs. 

Certain things would be faster and more easy to code. Like searching for
information and adding new information.

Other things, like simply opening an entire folder, would not only be
slower but also consume more memory. (a lot slower, actually)

With the cursor capability of SQLite, however!, it might be doable to
get something working that is comparable to what we currently have.

-- I don't know how well SQLite's cursor implementation works. But I can
imagine that it would yield comparable results. --

I don't know (but don't think it's a problem) if SQLite's engine allows
for multiple databases to be opened by one process. If not, that's a big
problem (again, I don't think this is a problem with SQLite).

It's something to take into consideration. I did consider it before, but
then figured that although you'd get acceptable results, a mapped file
would (given the limited set of functionality to support) offer you a
faster implementation that uses fewer memory (and does exactly what you
want it to do).



Note that using SQLite with its efficient cursor would require marrying
the GtkTreeModel with the summary storage and making the summary storage
a type that implements something that can be iterated (have a next and a
previous method). This implies a quite big change in the API, whereas
this experiment requires no API changes whatsoever.

Not something I'd make a big problem of, in Tinymail 2.0, but some
people might dislike having to redo certain pieces of their E-mail
client ;-)



-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be