Re: Patch: add header flag "calendar"

[Philip Van Hoof <spam pvanhoof be>]

This way, however, you enlarge TnyHeader's size by at least 4 bytes (an
entire pointer). Why? You are just storing a single bit.

You're apparently also adding a TnyHeaderSupportFlags, which is another
4 bytes. So that's 8 bytes to store a single bit.

Why not simply use one of the least significant bits of the existing
flags field?

I can't approve this either. Those TnyHeader instances occur very often.
So increasing its size by 8 bytes isn't acceptable.

On Tue, 2009-12-22 at 11:52 +0100, José Dapena Paz wrote:
> El vie, 18-12-2009 a las 13:04 +0100, Philip Van Hoof escribió:
> > On Fri, 2009-12-18 at 12:36 +0100, José Dapena Paz wrote:
> > 
> > > 	Then we need to find a different way. The approach taken in camel is
> > > storing this kind of information in the user flags, which is not
> > > supported in camel lite (and also, not exposed in any way to tinymail).
> > > As far as I remember, this is one of the things removed to keep small
> > > tinymail/camel-lite folder summary storage.
> > > 
> > > 	Or we can just add the user flags in this way:
> > > 	* CamelMessageInfo: same API
> > > 	* Add API to TnyHeader to get/set these flags
> > > 	* Add a way to know the degree of support for these flags in the header
> > > (no support, only memory storage, both memory and persistent storage).
> > > 
> > > 	void tny_header_set_user_flag (TnyHeader *header, const gchar *name, gboolean flag)
> > > 	void tny_header_get_user_flags (TnyHeader *header, TnyList *flags);
> > > 
> > > 	TnyHeaderSupportFlagsType tny_header_support_user_flags (TnyHeader *header);
> > > 	^----- How could this be better implemented? :m
> > > 
> > > 	Same for camel. We recover the userflags field. By default we would
> > > only support storage in memory, and we could allow to set in some way if
> > > support is also available to storage in disk. This info would be stored
> > > in the CamelFolderSummary. This way, if we have (as we have now) some
> > > provider that don't use the camel-lite summary, and provides special
> > > flags, we could add access to it.
> > 
> > 
> > This sounds good to me
> 
> 	This patch implements the proposal for user flags. Finally it's a bit
> different: we have a method tny_header_get_user_flag, and no way to
> retrieve all the available headers. This is just to mimic the behavior
> of the camel backend.
> 
> 	Also, default implementation in camel is not persistent (and then, no
> changes in summary format). But other backends may implement persistent
> storage or some or all user flags.
> 
> 	Attached is the patch implementation.
> 
> 
> > 
> > 
> 
> 

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