RE: Early-posting a new idea for the summary format
- From: <Dirk-Jan Binnema nokia com>
- To: <tinymail-devel-list gnome org>
- Subject: RE: Early-posting a new idea for the summary format
- Date: Fri, 2 Feb 2007 13:55:52 +0200
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]