Re: Patch: add header flag "calendar"

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2009-12-22 at 14:08 +0100, José Dapena Paz wrote:
> 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.
> 

I see

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

Hmm, so you want an arbitrary list of flags, not just a single on-off
switch?

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

It was ifdeffed away to avoid those 4 bytes ...

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

Yeah, in Camel the specific backends can already enlarge the
CamelMessageInfo thing. So this is what the specific backend that needs
this should indeed do then. Sounds like a good idea indeed.

Not sure how you'll expose it in TnyCamelHeader, shouldn't be too hard.
 

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