Re: [Evolution] Camel Folder api review

[NotZed <notzed helixcode com>]

> > On another note, i'm not sure how a messages 'flags' are
> > supposed to be set.  The folder implements the flags, but
> > the only setting function is on the messages;
>
> That's wrong then. The setting function should be on the folder.
>
> > /*  change to a bitmask
> >     GList *permanent_flags; */
>
> I'm not sure exactly what you mean by changing it to a bitmask. I
> don't think we should hardcode the set of flags available if that's
> part of what you're implying.

But for imap (am i right?), and for mbox (currently), we do have a
hardcoded set of flags to play with (in the mbox case, there
are 'some number of bits' - well 1 char, probably 6 bits, but
its totally unimplemented at the moment).  There's only a couple of
things they should be used for anyway (read/deleted/?).

There needs to be at least some way of specifying 'system'
flags.  A list of strings, including, say, "DELETED", doesn't
serve that purpose well.

> >     /* change these to a bitmask (or maybe bitfields) */
> >     gboolean can_hold_folders;
> > ...
>
> I don't think making them a bitmask/bitfields would really help
> anything. This isn't where we're going to be using up memory.

Its not memory, its how to store them.  And a given provider
only supports a fixed (hardcoded) subset of any such flags.

This follows the javamail api exactly, btw (using a bitmask,
or the equivalent of it).
(http://java.sun.com/products/javamail/javadocs/javax/mail/Flags.Flag.html)

> > /* it would be nice if this were typesafe (GLists suck) */
> >     GList *  (*list_subfolders)   (CamelFolder *folder, 
> >                                    CamelException *ex);
>
> You could make it return an array of whatever.

> That interface should go away and be replaced with the one currently
> in CamelFolderSummary though (or something like it) so you don't have
> to fetch all of the folders at once if there are a million of them.

Maybe an iterator interface?  Although i'm not sure you dont
want to cache all such info, anyway (in some cases the lists
aren't going to be big).  Or even if they are in some cases
you will always need to load the whole lot (say, to display
them), so having an iterative interface isn't actually
saving much at all (summary is a good example, since it
will normally be used to generate the etable contents in
its entirety, and be sorted and all sorts of things).

 Michael