Re: Support for the size attribute in TnyHeader

[Philip Van Hoof <spam pvanhoof be>]

And note that I might change this to become rounded on kilobytes. 

Reasoning for this: in bytes, with the internal field being a 16 bit
integer, it would mean that a maximum of 65535 bytes would stil be
correct. Anything above would overflow (it's handled as an unsigned
integer internally, so it wouldn't turn negative).

The guint tny_header_get_message_size (TnyHeader *header) API will still
return bytes, but rounded to 1024 (I will multiply it with 1024 in the
libtinymail-camel implementation).

Other than that is all this just internal (nothing to worry about for
most people, except that right now only 16 bits are available).

The reason why it's 16 bits is because the field is shared with the
flags attribute in memory (each consumes 16 bits of a 32 bit integer).

I don't see a point in having a byte-correct size value. I believe that
with kilobyte precision 99.999999999999999% of all people will be
satisfied. 


Especially if you know that byte precision would consume more memory
(with data alignment in mind, this can go up to 4 or 8 bytes per header,
depending on the architecture, on 10,000 headers that's 400kb of
memory).


On Tue, 2007-01-16 at 08:31 +0100, Philip Van Hoof wrote:
> I added support for the size attribute in TnyHeader. The API goes like
> this:
> 
> guint tny_header_get_message_size (TnyHeader *header)
> 
> It works on both POP and IMAP and on newly written headers, once they
> have been put in a TnyMsg, too (or, should .. but please test this new
> functionality. It's a candidate for a nice unit test).
> 
> This is in preparation for a size-limited retrieval strategy (which is
> different from partial retrieval in that it limits on message size).
> 
> 
-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://www.pvanhoof.be/blog