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

[JP Rosevear <jpr novell com>]

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?

-JP
-- 
JP Rosevear <jpr novell com>
Novell, Inc.