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

[Jeffrey Stedfast <fejj novell com>]

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.
fejj ximian com  - www.novell.com