Re: Patch: add header flag "calendar"

[José Dapena Paz <jdapena igalia com>]

El mar, 22-12-2009 a las 13:33 +0100, Philip Van Hoof escribió:
> This way, however, you enlarge TnyHeader's size by at least 4 bytes (an
> entire pointer). Why? You are just storing a single bit.

	The added space is exactly one pointer in CamelMessageInfoBase.

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

	No, it's implementation detail. The support flags are not stored, but
simply an override of the get_user_flag in camel. No actual storage.

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

	I don't get what you're proposing. We need to add a place to store a
list of flags, or any other object structure that can handle a list of
strings. Adding an arbitrary flag was discarded (this was what I
proposed in previous patch).

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

	The increase is 4 bytes. But anyway, there's no easy way to avoid this.
In fact it's a increase of 4 bytes on top of already 56 bytes of
previous format.

	Another possibility is make the default implementation of camel-lite
provide no user flag (and then, we don't need any storage in message
info base). Would it be ok? I will only need these user flags in a
specific camel backend, so removing support for generic camel folder
summary, imap and pop, would be ok.

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


-- 
José Dapena Paz <jdapena igalia com>
Igalia