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

[Harish Krishnaswamy <kharish novell com>]

I cannot agree more that it does look ugly but this cannot put into the
GW specific module because it would not have been loaded yet :)

The code for tracking if I had set up an idle function already - would
have to be added at this very abstraction again.
And since the open calendar calls are asynchronous, the password dialogs
for both the calendar and todo sources (but both for creating the same
calendar page in the GUI)  would pop out at the same time. And since
both are executed by the same thread - (gtk_main_loop) - i cannot (or i
do not see how) i can make one wait for the other to complete..
(the main loop would pop out the first dialog and while it waits for
input, call the next dialog also)

Any clues would be welcome.. 

GW is merely an example of a service provider that supports multiple
services - calendar, todo , addressbook requiring a single
authentication ( Exchange is another - but it plugs into the evolution
system differently with its own views at the front end). The right
approach may be to create separate abstractions for services and
accounts - so a backend provider can declare the services it provides
and let the higher abstractions figure out which e-sources are related
to one another and share a common authentication. As of today, the only
common link between them is the uri.

I am welcome to suggestions if this could be done better, if you can
help me see how.. 

harish


On Tue, 2004-06-15 at 06:51, Not Zed wrote:
> You can't do this, you can't hardcode a uri prefix into another
> unrelated abstraction layer.  If we did that all over the place we'd
> have an unmaintaintable monolithic mess of spaghetti.
> 
> Can't you just keep track of whether you've already setup an idle
> function for it and wait in that case?
> 
> 
> On Mon, 2004-06-14 at 22:04 +0530, Harish Krishnaswamy wrote: 
> > The patch below suppresses multiple password prompts for GroupWise
> > accounts in the Calendar component and is a fix for the bug #59386.
> > 
> > The Calendar source and the task source of a GroupWise account share the
> > same authentication tokens. The calendar component initiates the
> > asynchronous creation of a cal source as well as a task source (Task
> > summary in the Calendar view) in the same thread. (The gtk_main_loop
> > thread invokes the authentication callback function). 
> > This patch sets up the async_gw_auth_idle_cb function that delays the
> > authentication call for the second source till the first has had the
> > chance to obtain the password.
> > (This function can be used by any backend which provides both calendar
> > and task services as part of a single account).
> > 
> > harish
> > 
> > Index: ChangeLog
> > ===================================================================
> > RCS file: /cvs/gnome/evolution-data-server/calendar/ChangeLog,v
> > retrieving revision 1.290
> > diff -u -p -r1.290 ChangeLog
> > --- ChangeLog	14 Jun 2004 05:53:23 -0000	1.290
> > +++ ChangeLog	14 Jun 2004 16:19:04 -0000
> > @@ -1,4 +1,10 @@
> >  2004-06-14  Harish Krishnaswamy  <kharish novell com>
> > +	
> > +	* libecal/e-cal.c: (async_gw_auth_idle_cb), (async_auth_func_cb):
> > +	Fixes #59386. The calendar component for GW does not prompt for
> > +	password twice (for calendar and todo items).
> > +
> > +2004-06-14  Harish Krishnaswamy  <kharish novell com>
> >  
> > 
> >  	* backends/groupwise/e-cal-backend-groupwise-utils.c:
> > Index: libecal/e-cal.c
> > ===================================================================
> > RCS file: /cvs/gnome/evolution-data-server/calendar/libecal/e-cal.c,v
> > retrieving revision 1.68
> > diff -u -p -r1.68 e-cal.c
> > --- libecal/e-cal.c	2 Jun 2004 16:15:00 -0000	1.68
> > +++ libecal/e-cal.c	14 Jun 2004 16:19:05 -0000
> > @@ -1589,6 +1589,34 @@ typedef struct {
> >  } ECalAsyncData;
> >  
> >  static gboolean
> > +async_gw_auth_idle_cb (gpointer data)
> > +{
> > +	ECalAsyncData *ccad = data;
> > +	static gboolean authenticating = FALSE;
> > +	static gboolean cancelled = FALSE;
> > +
> > +	/* Check if Calendar authentication is already in progress */
> > +	if (!authenticating) {
> > +		/* If calendar authentication had been cancelled, 
> > +		 * todo authentication is considered cancelled as well. */
> > +		if (cancelled)
> > +			return FALSE;
> > +		authenticating = TRUE;
> > +		g_mutex_lock (ccad->mutex);
> > +		ccad->password = ccad->real_auth_func (ccad->ecal, ccad->auth_prompt,
> > ccad->auth_key, ccad->real_auth_user_data);
> > +		if (!ccad->password)
> > +			cancelled = TRUE;
> > +		g_cond_signal (ccad->cond);
> > +		g_mutex_unlock (ccad->mutex);
> > +		authenticating = FALSE;
> > +		return FALSE;
> > +	}
> > +	else 
> > +		return TRUE; /* this would cause the idle thread to be called again
> > and provide
> > +			      a chance for calendar authentication to be completed. */
> > +}
> > +
> > +static gboolean
> >  async_auth_idle_cb (gpointer data)
> >  {
> >  	ECalAsyncData *ccad = data;
> > @@ -1629,7 +1657,10 @@ async_auth_func_cb (ECal *ecal, const ch
> >  	ccad->auth_prompt = prompt;
> >  	ccad->auth_key = key;
> >  
> > -	g_idle_add ((GSourceFunc) async_auth_idle_cb, ccad);
> > +	if (!strncmp (ecal->priv->uri, "groupwise://", strlen
> > ("groupwise://")))
> > +		g_idle_add ((GSourceFunc) async_gw_auth_idle_cb, ccad);
> > +	else
> > +		g_idle_add ((GSourceFunc) async_auth_idle_cb, ccad);
> >  		
> >  	g_mutex_lock (ccad->mutex);
> >  	g_cond_wait (ccad->cond, ccad->mutex);
> > 
> > _______________________________________________
> > evolution-patches mailing list
> > evolution-patches lists ximian com
> > http://lists.ximian.com/mailman/listinfo/evolution-patches
> -- 
> 
> Michael Zucchi <notzed ximian com>
> 
> Ximian Evolution and Free Software
> Developer