Re: [evolution-patches] Patch for suppressing multiple password prompts in Calendar

[Harish Krishnaswamy <kharish novell com>]

On Mon, 2004-06-14 at 10:17, Not Zed wrote:


> You have all the info you need to identify the key at that point, so
> you're not breaking any abstraction layers by using it to optimise the
> password request.  Particularly since it appears that e-cal is doing
> the password requesting, not the backend (which seems wrong to me for
> a few reasons).

The backend should ideally initiate the authentication request not
e-cal. Point taken in principle.

> Well for starters you odn't block both the gui thread and the callee
> thread waiting for a synchronous reply.  Its actually a pretty risky
> way to do things, you're asking for deadlocks or other nasty
> behaviour.  Only the callee thread needs to be blocked for a
> synchronous call.  But to do it that way the request-auth callback
> would itself have to return the result via an asynchronous callback.
> But if the password requester was async, then it gives you a lot more
> control. 

No. Neither of the threads are blocked. The main thread uses an idle
callback for prompting the password dialog. So essentially, the patch
lets the first bidder (the calendar source) to proceed with the
authentication. The second bidder (also called by the main thread via
the idle_cb) would find if the first is still authenticating and then
return immediately with a TRUE value. As a result, it would be called
again and would so (at idle times) till the first authentication request
has completed (with either a success or a cancel). Thus the possibility
of a deadlock is avoided. 


> I was just trying to help, i'll leave it to JP and HPJ now
i understand.  No offence meant or taken :). We do need to explore the
model of the backend authenticating rather than ecal .

thanks,
harish