Re: [evolution-patches] [calendar-plugins]: fix for bug #305627

[chen <pchenthill novell com>]

On Fri, 2005-08-19 at 10:51 +0530, Harish Krishnaswamy wrote: 
> On Thu, 2005-08-18 at 10:06 -0700, Carsten Guenther wrote:
> > Hello? Does anyone care? 
> Yes..very much. gicmo's patch just crossed the 24-hr deadline and we are
> just human. A gentle nudge on the channel would do the trick as well :-)
> 
> > Can we revert that patch or at least check in 
> > Christian's changes?
> > 
> Just reviewed gicmo's changes. Look fine to me. 
> Chen, could you please add a Change Log to his patch and commit the
> same ?
Will add a ChangeLog and commit the patch, thanks. 
> 
> > Carsten Guenther wrote:
> > 
> > > I strongly feel that we should roll-back the original patch for the  
> > > following reasons:
> > >
> >  this is a "fix" for a non-critical enhancement request during  
> > > feature-freeze
> It is indeed just a bug fix (see #305627) that modifies a behavior not a
> huge enhancement or a new feature. So the feature-freeze has no bearing
> on this one.
> 
> > > 3. this patch not only introduces something Groupwise-specific (which  
> > > is a bad thing by itself) 
> I beg to disagree here - It applies to all providers that provide
> integrated mail/calendar service - It does benefit GroupWise - No reason
> why other providers in future cannot exploit this as well. 
> I guess all providers (not just  GroupWise) would prefer appointments
> sent from their servers getting handled by their Evolution backend
> stores directly. (Users when given a choice - might save it on other
> sources w/o realizing they lose provider-specific values)
> Everybody stands to gain here....
> 
> > but also introduces a performance penalty  
> > > for all the other providers
> > >
> Point taken. 
> Now that I am looking into this - wonder if we can exploit
> pitip->calendar_uid using X-EVOLUTION-DELEGATOR-CALENDAR-URI (or a
> similar one, since it already has a specific meaning) - 
> so nobody incurs unwanted penalties (big or small). 
> 
> Chen, any thoughts ??
Since the source uid would be a specific id w.r.t to a particular
machine, and there is no way for the other clients machines to know it,
it can't be used. We could probably think of mapping the email ids and
also provide an option to accept it in other calendars (which the
backends can decide upon). 

> 

I apologize for not replying soon. Had threaded view and since i just
sorted the mails in descending order on date, this reply went down the
list view and i completely missed it.

> Harish
> 
> _______________________________________________
> evolution-patches mailing list
> evolution-patches lists ximian com
> http://lists.ximian.com/mailman/listinfo/evolution-patches