Re: [Evolution-hackers] Recurrence woes

2006-08-02 Thread Jules Colding
On Tue, 2006-08-01 at 15:57 -0700, Scott Herscher wrote:
 Hey all.  I'm pretty close to getting recurrent events working (I
 think), but Evolution doesn't seem to want to behave.

Maybe this is something trivial like your get_static_capabilities()
implementation not returning the right capabilities for your backend??

HTH,
  jules


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] libecal and libedata-cal versions

2006-08-02 Thread Harish Krishnaswamy
On Mon, 2006-07-31 at 17:05 +0200, Øystein Gisnås wrote:
 When the version bump was commited to 2.6.x, it was not commited to
 the 2.7.x tree. Why was that? Because you only bump versions just
 before releases? I hope so. I noticed that libedata-cal versions were
 synced with 2.6.x in
 http://cvs.gnome.org/viewcvs/evolution-data-server/configure.in?r1=1.184r2=1.185.
 libecal was also bumped there, but AGE was not reset.
 
 Is the plan to reset AGE just before the final 2.8.0 release, or was
 it a mistake not to reset it before. The last thing we want is to
 release 2.8.0 with a lower SONAME version than 2.6.x..

Hi Øystein,

The recent libtool number bumps on libecal and libedata-cal do not map
to the corrective bump on 2.6.x (related to the recurrence changes).

slight digression

The changes pertain to the following (yet another ?) break on
libedata-cal

http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-cal-backend-cache.h?r1=1.16r2=1.17

that splits the calendar cache based on the component types. This change
was introduced to address a host of serious performance woes wrt to
remote servers that manipulate events, tasks and journals together.
You can find the details in my ChangeLog at

http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libedata-cal/e-cal-backend-cache.h


This also involved adding an introspective function to e-cal.h
http://cvs.gnome.org/viewcvs/evolution-data-server/calendar/libecal/e-cal.h?r1=1.30r2=1.31.


/slight digression

You are correct in pointing out that if this is left unchanged would
lead to a dubious condition where the later release ends up with a
SONAME version lesser than the previous stable branch.

I intend to set it right during the final release (both ecal and
edata-cal libraries need a correction) along with the camel lib bits.

Hope you can help me with some review on these proposed changes as well.

Thanks,
Harish

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Bug: win32 evolution windows filesystem.

2006-08-02 Thread Tor Lillqvist
on 2006-08-02 klockan 14:02 +0200 skrev Smartuser:

 I've noticed that when you want to connect for example to an IMAP server that 
 runs on a non standard port it wants to create a file with : in it 
 like .evolution/mail/[EMAIL PROTECTED]:2143 this failes becouse of windows 

Yup, known problem, needs to be fixed. (I guess I should really open a
bug in bugzilla for this.)

--tml


___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Recurrence woes

2006-08-02 Thread Scott Herscher
Hey Jules...thanks for responding.  It's not that...and I just learned 
something interesting.  I built evolution-data-server by hand, and then 
instrumented file backend...because it seems to work correctly.  I noticted 
that when there are recurrent exceptions, e-file-backend will return the entire 
calendar in get_object, instead of the single object that was being asked for.  
In other words, this is what it returns:

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VEVENT
UID:[EMAIL PROTECTED]
DTSTAMP:20060801T221427Z
DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/America/Los_Angeles:
 20060823T09
DTEND;TZID=/softwarestudio.org/Olson_20011030_5/America/Los_Angeles:
 20060823T10
TRANSP:OPAQUE
SEQUENCE:2
SUMMARY:aaa
CLASS:PRIVATE
RRULE;X-EVOLUTION-ENDDATE=20060827T16Z:FREQ=DAILY;COUNT=5;INTERVAL=1
CREATED:20060801T221446
LAST-MODIFIED:20060801T221446
END:VEVENT
BEGIN:VEVENT
UID:[EMAIL PROTECTED]
DTSTAMP:20060801T221427Z
DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/America/Los_Angeles:
 20060824T16
DTEND;TZID=/softwarestudio.org/Olson_20011030_5/America/Los_Angeles:
 20060824T17
TRANSP:OPAQUE
SEQUENCE:3
SUMMARY:aaa
CLASS:PRIVATE
CREATED:20060801T221446
LAST-MODIFIED:20060801T221457
RECURRENCE-ID:20060824T09
END:VEVENT
END:VCALENDAR

That doesn't make a whole lot of sense to me...maybe I just don't understand 
how it's supposed to work.  Harish or someone close to the project...can you 
explain this?

Thanks,

Scott


- Original Message -
From: Jules Colding [EMAIL PROTECTED]
To: Scott Herscher [EMAIL PROTECTED]
Cc: evolution-hackers@gnome.org
Sent: Tuesday, August 1, 2006 11:44:09 PM GMT-0800
Subject: Re: [Evolution-hackers] Recurrence woes

On Tue, 2006-08-01 at 15:57 -0700, Scott Herscher wrote:
 Hey all.  I'm pretty close to getting recurrent events working (I
 think), but Evolution doesn't seem to want to behave.

Maybe this is something trivial like your get_static_capabilities()
implementation not returning the right capabilities for your backend??

HTH,
  jules



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers