[Evolution-hackers] Re: camel_store_get_folder_info suckage

[Not Zed <notzed ximian com>]

On Sat, 2003-11-15 at 05:06, Jeffrey Stedfast wrote:
> ok, so I was right about the mbox code expecting NULL. but this may very

It should treat null and "" identically.

> well have been my fault. anyways, that is now fixed in CVS along with
> changes to set the fi->flags with CAMEL_FOLDER_CHILDREN,
> CAMEL_FOLDER_NOSELECT, and CAMEL_FOLDER_NOINFERIORS and the like.
>
> now for the new problem:
>
> if you call get_folder_info without the RECURSIVE flag, you only get a
> singleton fi returned to you. I guess this makes sense. (note, however,

Thats a bug in mbox, it should return 1 level.

> that imap will return one level of subdirs as well - altho they will be
> placed in fi->sibling rather than fi->child which is rather wrong).
Thats a bug in imap, or maybe build_folder_info which i never trusted.  Although this is how the subscription selector uses it, so either it works around it, or it (getfolderinfo) doesn't owrk this way.

> so... the only way to get a list of subfolders of an mbox folder is to
> request RECURSIVE. However, this scans more than just a single level
> which is not what I want.
But it also doesn't matter to do it this way.  Its no change from current behaviour.

> the way the IMAP spec deals with this, is by providing 2 modes of
> recursive: % (1 level) and * (everything)
>
> what do you think of having a
> CAMEL_STORE_FOLDER_INFO_RECURSIVE_ONE_LEVEL type flag?
Not necessary, see above.

> while on the subject of get_folder_info... the interface sucks. There
> are several reasons it sucks, but the ones I'm thinking of right now is
> that it doesn't allow for any sort of globbing and it is inconsistant

What do we need globbing for?  There's not a single place we'd use it.

> with the other camel-store methods in that the other methods take a path
> while get_folder_info takes a full_name.
Does it?  The imap code treats the incoming name/path exactly the same for get_folder_info as with rename_folder, get_folder, etc. (using the imapstoresummary to turn the incoming path into a physical 'full_name', which might not be en/de codable from the path because of bad encoding on the server).

> probably too late to change this interface tho. :-(

It got changed a year ago :)

 Z