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

[Not Zed <notzed ximian com>]

> > 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?

Only that it will be a camel api, and so ... quite a lot i'd imagine.
Unless you want to move all the backends into camel ;-).  Which isn't
such a crazy idea ... given the changes to the apis on the disksummary
branch, it would probably actually work remarkably well with only a few
more api changes and a fair bit of refactoring (and a truckload of work
for the addressbook/calendar backends!).

It isn't really any different from what we have now, but instead of
getting a tree structure, we just get an array.

I was just thinking
 GPtrArray *folders =
  camel_store_get_folder_info(store, pattern, flags, ex);
As opposed to
  CamelFolderInfo *fi =
   camel_store_get_folder_info(store, top, flags, ex);

The array is still items of CamelFolderInfo objects, and the
'full_name' (path) is used to build the ui tree from, rather than
child/parent pointers.

(i'm not really in any rush to do it, but given large api changes going
on in my branch it would probably make sense).

Given that 'folders' wont take up so much memory anymore, i'm inclined
to drop the entire CamelFolderInfo interface anyway, and just do things
off of real-live folder objects.  This FolderInfo crap just adds a very
annoying, quite complex, hard to manage meta-data layer ontop of the
physical layer anyway - entirely my fault, I should've followed
Bertrand's ideas and the JavaMail API closer in the first place, but for
performance i dont think we had much choice back then.

So, if I did that, i'd probably change the api even further:

 CamelFolderIterator *iter = 
	camel_store_get_folders(store, pattern, ex);

And then you can just iterate over the matches:
 CamelFolder *f;

while (f = camel_iterator_next(iter, ex)) {
	do something
}

Then again, if you did this too, you could just do:

// only gets a single level
Iter = get_folders(store, pattern, ex)

// gets children of folder 'folder'
Iter = get_folders(folder, pattern, ex)

Then remove all the duplicated rename/delete logic (again messy stuff
badly thought out) from CamelStore at the same time and just do that
from the folder objects directly.

(in which case, you've just ended up with something entirely different
to the initial proposal I had ... :-).