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

Re: [CalendarServer-dev] [CalendarServer] #207: Recurring events do not appear to extend beyond November 2008
by CalendarServer 28 Oct '08

28 Oct '08

#207: Recurring events do not appear to extend beyond November 2008 -------------------------------------+-------------------------------------- Reporter: dekkerdreyer(a)gmail.com | Owner: sagen(a)apple.com Type: Defect | Status: reopened Priority: 1: Blocker | Milestone: CalendarServer-2.0 Component: Calendar Server | Severity: Serious Resolution: | Keywords: -------------------------------------+-------------------------------------- Changes (by wsanchez(a)apple.com) * milestone: CalendarServer-2.x => CalendarServer-2.0 -- Ticket URL: <http://trac.calendarserver.org/ticket/207#comment:11> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #30: Need better logging
by CalendarServer 28 Oct '08

28 Oct '08

#30: Need better logging ---------------------------------+------------------------------------------ Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: closed Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Resolution: Software changed | Keywords: ---------------------------------+------------------------------------------ Changes (by wsanchez(a)apple.com) * status: assigned => closed * resolution: => Software changed Comment: I think our new log.py fits the bill. -- Ticket URL: <http://trac.calendarserver.org/ticket/30#comment:6> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #212: We should avoid the non-standard Connection.execute method in sqlite3.
by CalendarServer 28 Oct '08

28 Oct '08

#212: We should avoid the non-standard Connection.execute method in sqlite3. ------------------------------+--------------------------------------------- Reporter: dreid(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: assigned Priority: 2: Expected | Milestone: Later Component: Calendar Server | Severity: Crash/data loss Resolution: | Keywords: ------------------------------+--------------------------------------------- Changes (by wsanchez(a)apple.com) * priority: 1: Blocker => 2: Expected * status: new => assigned * milestone: Linux Port => Later -- Ticket URL: <http://trac.calendarserver.org/ticket/212#comment:1> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #252: Seriously Slow Performance, crawling (was: Seriously Slow Perfromance, crawling)
by CalendarServer 28 Oct '08

28 Oct '08

#252: Seriously Slow Performance, crawling --------------------------------+------------------------------------------- Reporter: silas(a)uoregon.edu | Owner: wsanchez(a)apple.com Type: Defect | Status: assigned Priority: 1: Blocker | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Performance Resolution: | Keywords: --------------------------------+------------------------------------------- -- Ticket URL: <http://trac.calendarserver.org/ticket/252#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #161: CalendarServer doesn't delete stray sockets on startup
by CalendarServer 28 Oct '08

28 Oct '08

#161: CalendarServer doesn't delete stray sockets on startup ---------------------------------+------------------------------------------ Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: assigned Priority: 1: Blocker | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Crash/data loss Resolution: | Keywords: ---------------------------------+------------------------------------------ Comment(by wsanchez(a)apple.com) Default location for `ControlSocket` is `/var/run/caldavd-pydir.sock`, which is not the logs dir, so that problem should be cleared up. Note that in `caldavd-test.plist`, it is `logs/caldavd.sock` because we don't want to create a bunch of runtime directories for development/testing. (You should not be deploying a server using the test config, use by using the `run` script; though I know some distros are incorrectly doing so.) -- Ticket URL: <http://trac.calendarserver.org/ticket/161#comment:10> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #161: CalendarServer doesn't delete stray sockets on startup
by CalendarServer 28 Oct '08

28 Oct '08

#161: CalendarServer doesn't delete stray sockets on startup ---------------------------------+------------------------------------------ Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: assigned Priority: 1: Blocker | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Crash/data loss Resolution: | Keywords: ---------------------------------+------------------------------------------ Changes (by wsanchez(a)apple.com) * status: new => assigned Comment: Is there an easy way to know that a socket file has no listener attached to it? That would be a reliable way to detect a stray socket. -- Ticket URL: <http://trac.calendarserver.org/ticket/161#comment:9> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #270: How should calendar discovery work?
by CalendarServer 28 Oct '08

28 Oct '08

#270: How should calendar discovery work? ------------------------------+--------------------------------------------- Reporter: agx(a)sigxcpu.org | Owner: wsanchez(a)apple.com Type: Defect | Status: closed Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Other Resolution: Completed | Keywords: ------------------------------+--------------------------------------------- Changes (by wsanchez(a)apple.com) * status: new => closed * resolution: => Completed Comment: If you start at your calendar principal (eg, for me, /principals/users/wsanchez/), then there are DAV properties to help you find you calendar homes. Also, if you start at /principals/ on our server, you can look up your own calendar principal URI via the DAV:current-user-principal-uri (or something) property. The idea there being that if you do an CalDAV SRV DNS record lookup for example.com, that would resolve to something like https://calendar.example.com/principals/, where you can then to the current-user-principal lookup, and then the rest of the CalDAV lookups. Is that enough info? -- Ticket URL: <http://trac.calendarserver.org/ticket/270#comment:1> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #105: Access log does not show file size on PUT
by CalendarServer 28 Oct '08

28 Oct '08

#105: Access log does not show file size on PUT -------------------------------+-------------------------------------------- Reporter: cdaboo(a)apple.com | Owner: sagen(a)apple.com Type: Defect | Status: new Priority: 4: Nice to have | Milestone: Later Component: Calendar Server | Severity: Other Resolution: | Keywords: -------------------------------+-------------------------------------------- Changes (by wsanchez(a)apple.com) * owner: cdaboo(a)apple.com => sagen(a)apple.com -- Ticket URL: <http://trac.calendarserver.org/ticket/105#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #240: _lookupVHostRecord still looks at XMLPlist
by CalendarServer 28 Oct '08

28 Oct '08

#240: _lookupVHostRecord still looks at XMLPlist ---------------------------------+------------------------------------------ Reporter: wsanchez(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: closed Priority: 2: Expected | Milestone: CalendarServer-2.0 Component: Calendar Server | Severity: Serious Resolution: Software changed | Keywords: ---------------------------------+------------------------------------------ Changes (by wsanchez(a)apple.com) * status: new => closed * resolution: => Software changed Comment: The ServicesLocator stuff was removed in trunk -- Ticket URL: <http://trac.calendarserver.org/ticket/240#comment:1> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #196: Any plans to merge the pydirector changes back upstream?
by CalendarServer 28 Oct '08

28 Oct '08

#196: Any plans to merge the pydirector changes back upstream? ------------------------------+--------------------------------------------- Reporter: agx(a)sigxcpu.org | Owner: agx(a)sigxcpu.org Type: Task | Status: new Priority: 3: Important | Milestone: Later Component: Calendar Server | Severity: Other Resolution: | Keywords: ------------------------------+--------------------------------------------- Changes (by wsanchez(a)apple.com) * owner: dreid(a)apple.com => agx(a)sigxcpu.org Comment: Guido, feel free to follow up. For what it's worth, `txLoadBalancer` (http://pypi.python.org/pypi/txLoadBalancer/) may be a better alternative for us, as it can be loaded into our server directly rather than forekd off to another proccess, and may give us more control. -- Ticket URL: <http://trac.calendarserver.org/ticket/196#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0