Re: [Evolution-hackers] CamelFolder updates

[Dan Winship <danw helixcode com>]

> 1) Fix the glib precondition stuff, fix the gtk-doc comments, etc.
> 
> 2) Remove deprecated methods:
> 
>    - async open/close mehthods
> 
>    - copy_message_to because it's a useless optimization

I did all that.

>    - list_subfolders and get_uid_list because they explode on Very
>      Large folders, whereas get_subfolder_info / get_message_info
>      don't.

OK, not doing that. I guess I'll punt get_subfolder_info and
get_message_info instead.

list_subfolders and get_uid_list both return GLists. I think GPtrArray
is a generally more useful type, since it's randomly accessible and
has a "length" element. Also, list_subfolders returns actual
CamelFolders, and I think there are cases where you'd rather have just
the names. (There are no places that actually call list_subfolders
currently.)

So my new proposal is to get rid of get_subfolder_info,
get_message_info, list_subfolders, and get_uid_list and replace them
with:

GPtrArray *get_uids  (CamelFolder *, CamelException *);
void       free_uids (CamelFolder *, GPtrArray *);

GPtrArray *get_subfolder_names  (CamelFolder *, CamelException *);
void       free_subfolder_names (CamelFolder *, GPtrArray *);

GPtrArray *get_summary  (CamelFolder *, CamelException *);
void       free_summary (CamelFolder *, GPtrArray *);

The first two get_*s return an array of strings, the last one an array
of CamelMessageInfo.

Or should there be something to return CamelFolderInfo structures
instead of subfolder names? (To get those, you have to actually create
and query CamelFolder objects, so it's more work.) Maybe have both
get_subfolder_names and get_subfolders (which would return
CamelFolders, not CamelFolderInfos... I think CamelFolderInfo turns
out to be an antioptimization.)

-- Dan