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

[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

UIDs as ATTENDEE IDs, please fix that
by Helge Heß 01 Jul '09

01 Jul '09

Hi, CalServer switched to use URNs/UIDs as ATTENDEE identifies. I think thats a really BIG mistake, I feel very strongly about it ;-) and would like to see that behaviour modified. Currently: ATTENDEE;X-CALENDARSERVER-EMAIL=abc@def.de:urn:uid:29838484... should be ATTENDEE;X-CALENDARSERVER-UID=29838484:mailto:abc@def.de or even ATTENDEE;X-CALENDARSERVER-UID=29838484:tel:+49-12234-233 Why? There are two big reasons: a) Interoperability. I would claim that all iCalendar clients use mailto ids today. Plus plenty of other iCalendar infrastructure. Changing this will result in interop issues and breaks a lot of stuff for (IMO) no good reason. b) The URN is completely opaque/proprietary to the client. It can't possibly resolve a URN to a contact database or other things which relate to attendees. This results in bad user experience and cross app integration at multiple levels. Note that my suggestion still includes a server specific UID which can be used for a stable resolution - as long as clients preserve it. And if not, its still sufficient for the far majority of real world deployments (reassigning email addresses is a no go, don't understand why people even consider that :-). Cyrus claims that this is not viable because clients throw away X- attributes. Does iCal do that? I think Kontact, Evo, Moz are all preserving such (we certainly do). Note: I'm fine with emitting URNs for stuff which can't possibly be resolved. Resources or locations _might_ be in that category, though I would still prefer an LDAP URL (+ UID X attr) if they are backed by something like OD. This still gives the client a way to learn about the ATTENDEE. Thanks a lot, Helge -- Helge Hess http://helgehess.eu/

3 13

[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

Invalidated resources with memcache implementation
by Eli Bach 20 May '09

20 May '09

When using open directory configure users/groups/locations/resources, with the new memcached caching implementation, what is the best way to handle the situation where -a user tries to invite a specific user email address in iCal, but the user isn't present is OD -so DCS adds that email address to the cache as being invalid -the user adds the user to OD -the user goes back to iCal to re-invite the user At this point, DCS seems to only use the cache entry, which still indicates the address is invalid. What should be done at this point? I've got a separate process that helps manage changes to the server, so I could send a signal to DCS or possibly to the memcached process, but what is the best way to handle this? Of course, the trivial, but extremely heavyweight option is to restart DCS. Eli

2 3

[CalendarServer] WikiStart modified
by CalendarServer 12 May '09

12 May '09

Changed page "WikiStart" by wsanchez(a)apple.com from 17.224.20.215* Page URL: <http://trac.calendarserver.org/wiki/WikiStart> Diff URL: <http://trac.calendarserver.org/wiki/WikiStart?action=diff&version=35> Revision 35 Comment: Add Twitter -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: WikiStart ========================================================================= --- WikiStart (version: 34) +++ WikiStart (version: 35) @@ -24,6 +24,7 @@ * [wiki:MailLists Mailing lists] * [wiki:IRC IRC channels] + * [http://twitter.com/calendarserver/ Twitter] = External Links = -------8<------8<------8<------8<------8<------8<------8<------8<-------- * The IP shown here might not mean anything if the user or the server is behind a proxy. -- CalendarServer </> HTTP/WebDAV/CalDAV Server This is an automated message. Someone at / added your email address to be notified of changes on WikiStart. If it was not you, please report to .

1 0