Re: Patch: add header flag "calendar"

[José Dapena Paz <jdapena igalia com>]

El mar, 22-12-2009 a las 14:32 +0100, Philip Van Hoof escribió:

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

	Yes, one that specific backends can use with their own semantic, and
that higher layers (or users of tinymail API) can access. And one that
different tinymail providers won't get problems to register in paralel.

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

	Sure. If we want to storage that information we need some place to
storage it.

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

	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.

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