RE: Last version of the new summary storage engine

[Dave Cridland <dave cridland net>]

On Mon Dec 10 22:23:21 2007, 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).
Well, it's more that IMAP imposes a 4G limit - it's an unsigned  
32-bit number - so there's no point in trying to support more. No  
email system will accept anything like 4G anyway.

> 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. 

For the stringy data, it might work out better. For the fixed-width  
data (UID, INTERNALDATE, MODSEQ, FLAGS-bitmap, etc), it'd be faster  
to use mmap(), although you lose the transactional fun.

Dave.
--
Dave Cridland - mailto:dave cridland net - xmpp:dwd jabber org
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade