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? _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
