August 2008 - calendarserver-dev - lists.macosforge.org

[CalendarServer] #281: all invocations of PyCObject_Check(pystate) should return a meaningful exception
by CalendarServer 17 Sep '08

17 Sep '08

#281: all invocations of PyCObject_Check(pystate) should return a meaningful exception -----------------------------+---------------------------------------------- Reporter: agx(a)sigxcpu.org | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: PyKerberos | Version: Severity: Other | Keywords: -----------------------------+---------------------------------------------- without this we see: SystemError: error return without exception set which is not very helpful -- Ticket URL: <https://trac.calendarserver.org/ticket/281> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

Re: [CalendarServer-dev] [CalendarServer] #228: REQUEST-STATUS value incorrectly encoded
by CalendarServer 29 Aug '08

29 Aug '08

#228: REQUEST-STATUS value incorrectly encoded ------------------------------+--------------------------------------------- Reporter: cdaboo(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: closed Priority: 2: Expected | Milestone: 1.x Component: Calendar Server | Version: Severity: Other | Resolution: fixed Keywords: | ------------------------------+--------------------------------------------- Changes (by sagen(a)apple.com) * status: new => closed * resolution: => fixed Comment: Committed a patch to vobject in svn.osafoundation.org (rev 209) -- Ticket URL: <http://trac.calendarserver.org/ticket/228#comment:4> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Fixing #207
by Peter Mogensen 22 Aug '08

22 Aug '08

Hi, I plan an attempt at fixing ticket #207 and would like to hear if there's any comments. SUMMARY (of current situaion): Events taking place more than 356 days from creation time will never be returned by indexed queries. Not even when you approach them. This means that events like "birthdays" will not work in the calendar. The iCal client is not affected by this, since it uses multiget REPORTS and ctag/etag to query the server. Other clients are though. DIAGNOSIS: * When events are store (PUT) they are expanded up to 356 days and any instances are put into the TIMESPAN index. A note (RECURRANCE_MAX) is made in the RESOURCE index of how far into the future TIMESPAN is valid. * When a calendar-query REPORT is made it will use an indexed query unless the query-parser/generator throws an exception saying that it does not handle such a query. This exception is currently not thrown when a comp-filter has a time-range element. * This means that indexed queries will still be used even if not all instances within the query time-range are in the TIMESPAN index. RECURRANCE_MAX is never updated or used. SOLUTION (wrt. the 1.2 code base): The solution must consist of two parts: 1) Recognize that a query will need to expand RECURRANCE_MAX. 2) Actually do the expansion for at least those events which has RECURRANCE_MAX < "end" for the time-range specified in the query. ad 1) The handling of filters is done in twistedcaldav/query/calendarquery.py:sqlcalendarquery() which is called from index.py:search() and searchValid() The code in twistedcaldav/query doesn't have access to the index, so any checking of RECURRANCE_MAX must be done in search()/searchValid() But only the code in twistedcaldav/query knows if there is a time-range and it is necessary to check RECURRANCE_MAX. So we need to change the prototype of sqlcalendarquery() to tell the index not only the SQL qualifiers, but also what it demands of the index to be able to use them. (like RECURRANCE_MAX > some-value - taken from time-range "end"). If search()/searchValid() gets such a demand, it must check the RESOURCE table and maybe do further expansion of events before running the query. ad 2) The easiest way here seems to call ical.py:expandTimeRanges() with a new limit and either replace the index values as if the resource has been PUT again, or filter out those instances which are before RECURRANCE_MAX and add the rest to the index. /Peter

2 3

use of X-CALENDARSERVER-ACCESS
by Robert Chien 18 Aug '08

18 Aug '08

Hi, I'm new to this list (and CalDAV in general), and apologize if this question has been asked before. A search of the 2008 archives came up empty. My question is about the use of X-CALENDARSERVER-ACCESS in the Darwin Calendar Server. But allow me to start with a little background: I wanted to see if iCal can handle private events when the calendar is hosted on a CalDAV-compliant server, and I came across this article: http://support.apple.com/kb/TS1694 , which suggests if the server supports private events, the option automatically unlocks in iCal. "Weird," I thought, as I have not seen any other Apple apps adapt themselves based on server capability. But sure enough, after downloading and configuraing darwin calendar, the private option appears in iCal. A colleague asked if it uses CLASS property as defined in RFC 2445, so I looked at the ics file, and found X-CALENDARSERVER-ACCESS instead. After a while I found caldav-privateevents.txt, which details how other CalDAV servers can also unlock the private option in iCal, but it doesn't explain why X-CALENDARSERVER-ACCESS was chosen over CLASS in the first place. Can someone explain this to me? I'm sure there's a reason. Thanks, Robert

3 2

Outlook bi-directional syncronization
by Mauricio Larrea 15 Aug '08

15 Aug '08

Hello guys!!!, Just to know if some of you already had the change to try bi-directional synchronization between Calendar Server and MS Outlook . Thanks in advance for your lights. Mauricio

2 1

GET with if-none-match
by Helge Heß 14 Aug '08

14 Aug '08

Hi, I'm using GET with an if-none-match header to check whether content changed on the server, it looks like: If-None-Match: "20080725T101321Z-0", "20080725T101321Z-0"-gzip CalServer always returns me the full content, that is a 200 OK status. (I'm expecting a 304). Is it possible that CalServer/TwistedCalDAV does not check all the given tags for a match? Or does it use a different etag with content-encoding content, like Apache? Thanks, Helge -- Helge Hess http://zideone.com/

2 2

Re: [CalendarServer-dev] [CalendarServer] #228: REQUEST-STATUS value incorrectly encoded
by CalendarServer 14 Aug '08

14 Aug '08

#228: REQUEST-STATUS value incorrectly encoded ------------------------------+--------------------------------------------- Reporter: cdaboo(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: new Priority: 2: Expected | Milestone: 1.x Component: Calendar Server | Version: Severity: Other | Resolution: Keywords: | ------------------------------+--------------------------------------------- Comment (by wsanchez(a)apple.com) vobject is updated to r208 in trunk. Dunno if this is fixed in that version. -- Ticket URL: <http://trac.calendarserver.org/ticket/228#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

[CalendarServer] #299: The twisted branch dav-acl-1608-4 no longer exists
by CalendarServer 14 Aug '08

14 Aug '08

#299: The twisted branch dav-acl-1608-4 no longer exists ---------------------------------------+------------------------------------ Reporter: illtud.daniel(a)llgc.org.uk | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 1: Blocker | Milestone: Component: Calendar Server | Version: Severity: Serious | Keywords: ---------------------------------------+------------------------------------ The run script tries to dl a branch of twisted: svn_uri="${proto}://svn.twistedmatrix.com/svn/Twisted/branches/dav- acl-1608-4"; That branch no longer exists in the twistedmatrix repository. I think maybe the dav-acl-1608-* branches have been merged into the trunk. I'm setting it to blocker because without this fix you can't build CalendarServer -- Ticket URL: <https://trac.calendarserver.org/ticket/299> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 1

'component' parameter in content-type
by Helge Heß 14 Aug '08

14 Aug '08

Hi, small wish: could iCalServer set the 'component' property in resource content-types? This would make in-place filtering of PROPFIND results easier: http://www.faqs.org/rfcs/rfc2447.html Sample: Content-Type:text/calendar; charset=UTF-8; component=vevent Thanks, Helge -- Helge Hess http://helgehess.eu/

2 1

[CalendarServer] #298: PROPFIND on existing collection returns 404
by CalendarServer 14 Aug '08

14 Aug '08

#298: PROPFIND on existing collection returns 404 -------------------------------+-------------------------------------------- Reporter: helge(a)zideone.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: trunk Severity: Other | Keywords: -------------------------------+-------------------------------------------- I'm getting a weird 404 as a response to a PROPFIND. The strange thing is that a PROPFIND from Cadaver works. So I suppose one of the requested properties which triggers the 404? But why is the whole result reported 404 then? Something is fishy ;-) Its trunk from today. ---snip--- 192.168.0.125 - - [25/Jul/2008:14:27:45 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 401 141 "-" "ZideOne/0.8.3 neon/0.27.2" [232.4 ms] 192.168.0.125 - user01 [25/Jul/2008:14:27:45 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 404 113 "-" "ZideOne/0.8.3 neon/0.27.2" [116.5 ms] 192.168.0.125 - user01 [25/Jul/2008:14:27:46 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 404 113 "-" "ZideOne/0.8.3 neon/0.27.2" [29.3 ms] 192.168.0.111 - - [25/Jul/2008:14:29:27 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 401 141 "-" "cadaver/0.23.2 neon/0.27.2" [51.7 ms] 192.168.0.111 - user01 [25/Jul/2008:14:29:33 +0200] "PROPFIND /calendars/users/user01/ HTTP/1.1" 207 3062 "-" "cadaver/0.23.2 neon/0.27.2" [118.1 ms] ---snap--- -- Ticket URL: <https://trac.calendarserver.org/ticket/298> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 4