RE: Early-posting a new idea for the summary format

[<Dirk-Jan Binnema nokia com>]

Hi, 

>-----Original Message-----
>From: ext Philip Van Hoof [mailto:spam pvanhoof be] 
>Sent: Friday, February 02, 2007 13:06
>To: Binnema Dirk-Jan (Nokia-M/Helsinki)
>Cc: tinymail-devel-list gnome org
>Subject: RE: Early-posting a new idea for the summary format
>
>On Fri, 2007-02-02 at 09:18 +0200, Dirk-Jan Binnema nokia com wrote:
>
>> >
>> >Basic question and reason for posting this: what do you 
>guys think of 
>> >it?
>> 
>> Uhm, basic question - what is the problem you are trying to solve?
>
>I want to make adding new summary information less intrusive. 
>At this moment adding new summary information means that the 
>entire summary file will eventually have to be rewritten.
>
>I would rather want it to only write the new information to a 
>file, and mmap that one once it reached a certain amount. But 
>if I would do that, the changes would be large enough to also 
>change the format.
>
>The format I would change for the simple fact that string 
>duplicates are common in it. They can be avoided easily and 
>avoiding it would drastically reduce the amount what must be 
>mmap()ed. Hence the ALIAS stuff.

Mhwww... I am not so convinced about the duplicate string
argument; say, in a mail folder I have 100 mails (and that's a lot!)
with the subject "This is my subject"; by just storing it once,
I will save 99x18 = 1782 bytes. That is not a lot, and of course
it adds some complexity, and makes the summary files quite
fragile.

Also note that embedded systems (like the 770/N800) often use 
compressed file systems (jffs2), which make the savings even
less.

>I would also take out the flags and put those in a different 
>file, as a read-write mmap. Same reason: level wearing of 
>flash devices, avoiding total rewrites, etc etc. 

Flash wearing should not be such a big problem, I think. But
taking out those flags might be interesting. Dunno.


>> >"W" means "word length". On a 32 bit computer this is 4 bytes, on a 
>> >64 bit computer this is 8 bytes.
>> [...]
>> 
>> Would that mean that 32-bit roadmaps are not readable by a 64-bit 
>> program? It's not uncommon to switch between 32 and 64 bit mode on, 
>> say, an AMD64 - it would suck if the summaries would be unreadable.
>
>That is what it means, yes. Though the summary mmaps could be 
>converted between different architectures, but not without a tool.

I guess it would be better to use the 32-bit 'words' on 64 bit platforms
as well. Otherwise, people who share their homedir between different
platforms will get screwed.

Best wishes,
Dirk.