[Evolution-hackers] Camel proposal: Manage folder lists, not folder trees

[Not Zed <notzed ximian com>]

So there's one particular interface in camel which always seems a pain
to implement right for each provider - get_folder_info().

It tries to be 'smart' and return a tree of all folders corresponding to
the query passed.  Things get particularly ugly when you start renaming
things.  They're hard to generate, and they're hard to use - in almost
all cases we simply flatten the list and sort it to use it anyway.
Often from a flat list that was converted to a tree just so it could
conform to the interface in the first place.

The one case we actually need this - so that namespaces dont blow out
the tree with redundant path elements - we can get around anyway, by
just not creating phantom parents for unknown path elements.

All of this logic is required for vfolders already.  The vfolder store
is going away entirely in the disksummary branch, so I think it makes
sense to solve the problem in one place in the client and simplify all
the backends.

This will only be happening on the disksummary branch anyway.

While i'm there i'm going to have to re-do most of em-folder-tree-model
(to actually drive its own model, not use that nasty memory model stuff
- goodbye a whole tree of gtktreerowreferences), and consequently lots
of em-folder-tree, probably most of mail-vfolder.c wont be needed, and
this will finally let me remove mail-folder-cache too (ahh, cascading
changes, dont you love it), as that is just a sort of meta-model of all
the stores, which is exactly what em-folder-tree-model is too.

Any reason not to do this?