Re: Async asking for folders

[Philip Van Hoof <spam pvanhoof be>]

http://pvanhoof.be/blog/index.php/2006/05/04/tinymail-asynchronous-folder-synchronization-with-the-service-implemented

On Thu, 2006-05-04 at 13:14 +0200, Philip Van Hoof wrote:
> 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