March 2009 - calendarserver-dev - lists.macosforge.org

[CalendarServer] #304: digest service requires undocumented realm parameter
by CalendarServer 26 Oct '09

26 Oct '09

#304: digest service requires undocumented realm parameter ------------------------------------+--------------------------------------- Reporter: msantos(a)santosland.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: trunk Severity: Other | Keywords: ------------------------------------+--------------------------------------- The Apache digest directory service requires the undocumented realmName parameter. This parameter should be added to the docs, and to the sample configuration file provided in the distribution. -- Ticket URL: <http://trac.calendarserver.org/ticket/304> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #303: Support 'component'(=VEVENT, VTODO) parameter in getcontenttype properties of PROPFIND results
by CalendarServer 26 Oct '09

26 Oct '09

#303: Support 'component'(=VEVENT,VTODO) parameter in getcontenttype properties of PROPFIND results -------------------------------+-------------------------------------------- Reporter: helge(a)zideone.com | Owner: wsanchez(a)apple.com Type: Enhancement | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: Severity: Other | Keywords: -------------------------------+-------------------------------------------- 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 }}} Rational: In Outlook we need to map a single calendar collection to two (or three) Outlook folders, eg "Calendar (Events)" and "Calendar (Tasks)". In Outlook each folder has a distinct type (its either tasks or events, never both). So when we do a PROPFIND on a CalDAV calendar which supports both (calendar-component-set: VEVENT+VTODO), tasks and events (and journals ...), we currently just get the generic text/calendar type. We need to fetch the content to decide whether the item is relevant or not for a specific Outlook folder type. If the server would report the contained component-type, we could avoid that annoyingly hard work ;-) Thanks PS: obviously the client can't (and shouldn't) rely on that parameter, but its a relevant optimization. -- Ticket URL: <http://trac.calendarserver.org/ticket/303> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 3

[CalendarServer] #297: Incorrect treatment of Depth on REPORTs
by CalendarServer 26 Oct '09

26 Oct '09

#297: Incorrect treatment of Depth on REPORTs ---------------------------------+------------------------------------------ Reporter: navara(a)emclient.com | Owner: cdaboo(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: CalDAV Tester | Version: Severity: Other | Keywords: ---------------------------------+------------------------------------------ CalDAVTester incorrectly sends calendar-query REPORTs with no Depth header and expect it to match on the contents of the collection. No Depth header is equivalent to Depth: 0 as per RFC 4791 and RFC 3253 (section 3.6), so no matching on child resources should be performed by the server. This results in the failure of reports.xml tests and possibly others. -- Ticket URL: <https://trac.calendarserver.org/ticket/297> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #277: Set process name
by CalendarServer 26 Oct '09

26 Oct '09

#277: Set process name --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 3: Important | Milestone: 2.x Component: Calendar Server | Version: Severity: Other | Keywords: --------------------------------+------------------------------------------- Server should do `setproctitle` or whatever to set the process name so that it isn't `python`, which makes it harder to distinguish from other python programs. I think this would require a C extension, since Python doesn't provide API for it. -- Ticket URL: <https://trac.calendarserver.org/ticket/277> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #274: caldavd does not properly quote parameters
by CalendarServer 26 Oct '09

26 Oct '09

#274: caldavd does not properly quote parameters ---------------------------------+------------------------------------------ Reporter: kmdurbrow(a)gmail.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: Severity: Other | Keywords: ---------------------------------+------------------------------------------ Last line of caldavd {{{ ${configfile} }}} should be quoted -- Ticket URL: <https://trac.calendarserver.org/ticket/274> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #319: A solution is needed when max_allowed_instances is exceeded.
by CalendarServer 26 Oct '09

26 Oct '09

#319: A solution is needed when max_allowed_instances is exceeded. -----------------------------+---------------------------------------------- Reporter: apm@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Serious Keywords: | -----------------------------+---------------------------------------------- With the ability to create events longer into the future the possibility that a user will create an event with more than "max_allowed_instances" (currently 1000) increases. From instance.py: # The maximum number of instances we will ezpand out to. # Raise a TooManyInstancesError exception if we exceed this. max_allowed_instances = 1000 ... which will make events disappear from instance 1000 or not get created at all if you place the mother event sufficiently far back in the past. If - say - your default_future_expansion_duration is 2 years, you currently cannot create a daily recurring event with a motherevent before ~ april 2008. Or if you create a daily recurring event today, it will no longer work after 1000 days. I see no good solution to this without some mechanism for the user to clean up old calendars, so the don't unnecessarily contain - say - 5 year old daily events. -- Ticket URL: <http://trac.calendarserver.org/ticket/319> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #286: ./run script have Perl run-time dependency.
by CalendarServer 13 Sep '09

13 Sep '09

#286: ./run script have Perl run-time dependency. ------------------------------+--------------------------------------------- Reporter: bland(a)bbnest.net | Owner: wsanchez(a)apple.com Type: Enhancement | Status: new Priority: 4: Nice to have | Milestone: Component: Calendar Server | Version: trunk Severity: Other | Keywords: ------------------------------+--------------------------------------------- ./run script uses xpath utility to fetch values out of caldavd.plist. This utility is Perl based and adds excessive dependency to CalendarServer bundle. It will be nice to switchover to PyXML inline code instead. -- Ticket URL: <https://trac.calendarserver.org/ticket/286> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 2

[CalendarServer] #325: Update CalendarServer to use a more recent version of Twisted
by CalendarServer 19 Jun '09

19 Jun '09

#325: Update CalendarServer to use a more recent version of Twisted ---------------------------------------+------------------------------------ Reporter: exarkun@… | Owner: wsanchez@… Type: Task | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ CalendarServer currently uses the dav-acl-1608-4 branch of Twisted. Twisted development has moved on significantly from that point and CalendarServer has accumulated a lot of changes relative to the branch, some specific to the webdav code, others in various other parts of Twisted. Updating CalendarServer to a more recent branch of Twisted - specifically, the dav-take-two-3081-3 branch - will allow it to stop carrying some of these patches immediately and is the first step towards integrating the rest back into Twisted. -- Ticket URL: <http://trac.calendarserver.org/ticket/325> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 3

[CalendarServer] #323: cat command on a directory returns HTML page
by CalendarServer 29 Apr '09

29 Apr '09

#323: cat command on a directory returns HTML page -------------------------------------+-------------------------------------- Reporter: mail@… | Owner: cdaboo@… Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: CalDAV Client | Severity: Other Keywords: | -------------------------------------+-------------------------------------- Since Linux upgrade to Lenny, the command 'cat' of 'CalDAVClientLibrary/runshell.py' returns HTML instead of an ics text if the argument is a directory. E.g. calling 'cat calendars/users/me/calendar/f0e947e9.ics' works fine, but 'cat calendars/users/me/calendar' returns the same HTML page, as if you use a web browser (<html><head><title>Collection listing for /calendars/users...). -- Ticket URL: <http://trac.calendarserver.org/ticket/323> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 1

[CalendarServer] #329: memcached cannot find libevent.so
by CalendarServer 28 Apr '09

28 Apr '09

#329: memcached cannot find libevent.so ---------------------------------+------------------------------------------ Reporter: macosforge@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Other Keywords: | ---------------------------------+------------------------------------------ On ubuntu linux, I get the following error: {{{ 2009-03-24 00:00:16+0100 [-] [memcached] ../memcached-1.2.6/_root/bin/memcached: error while loading shared libraries: libevent-1.4.so.2: cannot open shared object file: No such file or directory }}} ldd does show the correct link: {{{ arnouten@bird:~/dev/calendaring/CalendarServer$ ldd ../memcached-1.2.6/_root/bin/memcached linux-gate.so.1 => (0xb7f28000) libevent-1.4.so.2 => /home/arnouten/dev/calendaring/libevent-1.4.8-stable/_root/lib/libevent-1.4.so.2 (0xb7ef4000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d7b000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7d61000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7d48000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7d3f000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7d2b000) /lib/ld-linux.so.2 (0xb7f0e000) }}} /home/arnouten/dev/calendaring/libevent-1.4.8-stable/_root/lib/libevent-1.4.so.2 indeed exists (though it is a symlink). Starting memcached from the commandline appears to work. For now worked around this by setting both ClientEnabled and ServerEnabled to 'false' in conf/caldavd-dev.plist -- Ticket URL: <http://trac.calendarserver.org/ticket/329> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 9