Re: Patch: add header flag "calendar"
- From: Philip Van Hoof <spam pvanhoof be>
- To: José Dapena Paz <jdapena igalia com>
- Cc: tinymail-devel-list <tinymail-devel-list gnome org>
- Subject: Re: Patch: add header flag "calendar"
- Date: Tue, 22 Dec 2009 13:33:38 +0100
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
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
] [Thread Prev