On Tue, 2005-06-14 at 08:40 -0400, JP Rosevear wrote: > On Tue, 2005-06-14 at 10:33 +0800, Not Zed wrote: > > 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? > > Not off hand, but what exactly will be the API that will retrieve the > list of folders, and is there anything about it that means it couldn't > be re-used by calendar/tasks/contacts in EDS?
it could just return a flat list of folder items (think CamelFolderInfo but as a flat linked list rather than parent/child/sibling nodes). I don't see how this could make it unusable by other components - in fact, it'd probably make it simpler. -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com _______________________________________________ evolution-hackers maillist - [email protected] http://lists.ximian.com/mailman/listinfo/evolution-hackers
