Async asking for folders

[Philip Van Hoof <spam pvanhoof be>]

I added one async method to the TnyMsgFolderIface type:

The refresh_headers_async method. This method (if implemented) will
launch a thread which will refresh the headers by asking the server for
new information (synchronization with the IMAP server).

If you use it, it's highly recommended not to use the synchronous method
get_headers anymore. I will, however, try to make sure things work as
expected and in a thread-safe manner (which is not easy).

When using the refresh_headers_async method, the TnyGetHeadersCallback
delegate will not happen in that launched thread: the system will will
connect to the GMainLoop of your application and launch the callback in
the GMainLoop. This means that you don't have to worry about thread
safety in the callback handler: it's like a Button Clicked event.

You do, however, have to reassign the model to the treeview in the
callback handler. Take a look at the TnySummaryWindow implementation in
the demo-ui. It's simple.

I fear the usage of a thread is inevitable here. Unless I implement a
state machine and start doing dirty tricks with setjmp and longjmp which
might not be implemented or implementable on your architecture. I also
don't think Camel could cope with that. Also note that Camel is also
using a few threads at some points in time (it depends). But I do agree
it's a pity that I have to introduce this one thread.

But then again, it's optional. You can also use the synchronous API
which the demo-ui has been using since this change. The main drawback of
the synchronous API is that if a folder was never viewed before, the ui
hangs until Camel synchronized the folder locally. This takes a certain
amount of time: your user will not like it.

The asynchronous API will, however, not block your ui mainloop. But will
as drawback use a thread internally. And mixing the asynchronous and
synchronous APIs might not work or might get you in trouble at this
point.

I'd be very happy to accept patches that get all threading and locking
in libtinymail so correct that even that would work. The pain here is
mainly that I didn't use an iterator but in stead a GList which I can't
lock for passing the list of headers to the custom tree model. I think
the best solution would be to re-implement the custom tree model using
an iterator in stead of a GList. Other suggestions?


I have no idea how to document this in such a way that nobody will mix
the two APIs ;-). SO I might refactor getting the headers from the
folder type into a strategy design pattern: So that you can set the
strategy for getting headers: async or sync.  What do you guys think?

Anyway ... important is: the API is again changing a lot.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be