Re: [Evolution-hackers] Going about the solution for the bug 272964 [calendar]

[JP Rosevear <jpr novell com>]

On Mon, 2005-04-18 at 23:25 +0530, chenthill wrote: 
> Hi, 
>    The reason for the hang (may also cause inresponsiveness) is that
> when the source selection is changed from the appointment editor we
> create a new client and open a client in a synchronous manner. If the
> server takes some time to respond during authentication, evolution would
> be inresponsive during that time. 
> 
> This bug can occur in two cases
> 1) When server does not respond (or may take some time to respond)
> during authentication in the e_cal_open call.
> 2) When EDS does not respond (or responds after some time) to e_cal_open
> call.
> 
> Have sorted out some solutions for this problem
> 
> Solution 1: Opening of the calendar in async manner (e_cal_open_async).
> For the time the client is loading, disable the appointment editor
> except for the Cancel button. And in the "prompt for saving changes"
> dialog disabling the Save Changes button. Enable the GUI once the client
> is loaded. We can possibly show the loading status in the status bar.
> 
> Solution 2: Sharing the loaded clients between the editor and the model.
> Disabling the menu option in the e-source-option-menu (in appointment
> editor) for the clients which are not loaded. Here we should be handling
> cases when the client is in BUSY state.
> 
> Any comments or other better solutions to fix this problem would be
> appreciated.

Perhaps what we really want is more what the addressbook, a notification
of whether or not the backend is writable that is independent of the
open.  That way when going off line a backend might be able to indicate
its not longer writable or if the perms change on the server.  Or in the
more general case an ACL notification system.

I don't think you want 2) because the editor is going to end up in EDS
at some point and this might not be possible.

As for one, I think harish's approach for free/busy of just creating a
new thread and opening it synchronously might be better.

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