Re: Patch: add header flag "calendar"

[Philip Van Hoof <spam pvanhoof be>]

On Tue, 2009-12-22 at 17:20 +0100, José Dapena Paz wrote:

> > Not sure how you'll expose it in TnyCamelHeader, shouldn't be too hard.
> 
> 	Exactly same api. No change in camel level. Only change would be in
> camel folder summary default implementation, that would tell it does not
> support any flag. And specific impleemntations of info_set_user_flag and
> info_user_flags could override it providing any level of storage.
> 
> 	This way we provide the API, we  just implement a stub (no support for
> flags) in our default backends so no storage increase.
> 

Sounds good to me

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