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

[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] BadContent modified
by CalendarServer 21 Jul '09

21 Jul '09

Changed page "BadContent" by wsiegrist(a)apple.com from 17.151.97.7* Page URL: <http://trac.calendarserver.org/wiki/BadContent> Diff URL: <http://trac.calendarserver.org/wiki/BadContent?action=diff&version=3> Revision 3 -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: BadContent ========================================================================= --- BadContent (version: 2) +++ BadContent (version: 3) @@ -2,4 +2,5 @@ (?i)sneakeralley.com (?i)tagnice.com (?i)amazon.com +(?i)acesynergy.com }}} -------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 BadContent. If it was not you, please report to .

1 0

DummyTransport instance has no attribute 'loseConnection'
by Helge Heß 19 Jul '09

19 Jul '09

Hi, is this a bug, or can we ignore it: ---snip--- 2009-07-19 19:35:50+0200 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.memcachepool.MemCachePool#debug] Clients #free: 1, #busy: 0, #pending: 0, #queued: 0 2009-07-19 19:35:50+0200 [-] Unhandled Error Traceback (most recent call last): File "/Users/helge/Developer/Collaboration/Twisted/twisted/python/ log.py", line 84, in callWithLogger return callWithContext({"system": lp}, func, *args, **kw) File "/Users/helge/Developer/Collaboration/Twisted/twisted/python/ log.py", line 69, in callWithContext return context.call({ILogContext: newCtx}, func, *args, **kw) File "/Users/helge/Developer/Collaboration/Twisted/twisted/python/ context.py", line 59, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File "/Users/helge/Developer/Collaboration/Twisted/twisted/python/ context.py", line 37, in callWithContext return func(*args,**kw) --- <exception caught here> --- File "/Users/helge/Developer/Collaboration/Twisted/twisted/internet/ selectreactor.py", line 146, in _doReadOrWrite why = getattr(selectable, method)() File "/Users/helge/Developer/Collaboration/Twisted/twisted/internet/ process.py", line 242, in doRead return fdesc.readFromFD(self.fd, self.dataReceived) File "/Users/helge/Developer/Collaboration/Twisted/twisted/internet/ fdesc.py", line 94, in readFromFD callback(output) File "/Users/helge/Developer/Collaboration/Twisted/twisted/internet/ process.py", line 245, in dataReceived self.proc.childDataReceived(self.name, data) File "/Users/helge/Developer/Collaboration/Twisted/twisted/internet/ process.py", line 750, in childDataReceived self.proto.childDataReceived(name, data) File "/Users/helge/Developer/Collaboration/Twisted/twisted/internet/ protocol.py", line 436, in childDataReceived self.outReceived(data) File "/Users/helge/Developer/Collaboration/Twisted/twisted/runner/ procmon.py", line 83, in outReceived self.output.dataReceived(data) File "/Users/helge/Developer/Collaboration/Twisted/twisted/ protocols/basic.py", line 237, in dataReceived return self.lineLengthExceeded(exceeded) File "/Users/helge/Developer/Collaboration/Twisted/twisted/ protocols/basic.py", line 294, in lineLengthExceeded return self.transport.loseConnection() exceptions.AttributeError: DummyTransport instance has no attribute 'loseConnection' 2009-07-19 19:36:15+0200 [-] [notifications] 2009-07-19 19:36:15+0200 [-] [twistedcaldav.notify.XMPPNotificationFactory#debug] SEND: <presence/> ---snap--- Thanks, Helge -- Helge Hess http://zideone.com/

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service
by CalendarServer 18 Jul '09

18 Jul '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: sagen@… Type: Feature | Status: new Priority: 2: Expected | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by rahul@…): Replying to [comment:27 oxullo@…]: > Rahul, > availability's lookup doesn't work due to a small bug: every mail should be stored in the directory record object (after being read from LDAP) with RFC2368 scheme. > Please note that I had an issue with TB3b2+L1p2 (due to a Lightning's bug, filed as 435854 [https://bugzilla.mozilla.org/show_bug.cgi?id=435854 1]): whenever an user has a calendar with an empty inbox, Lightning starts to burst the server with polls. Can you tell me if you experience the same? > > I attach a patch which: > > * fixes availability lookup > * fixes the support for resources and locations > * adds the possibility to create delegation of resources and location via CalDAV compliant clients (like CalDAVClientLibrary) > > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=435854 Thanks for the patch Oxullo. It worked perfectly :). I tested for the bug which you have mentioned. I did not experience anything as such. But I am not sure if I followed the procedure for testing it properly. We shall be using this anyway in a production environment. So I should be able to give you feedback once it is deployed. -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:28> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service
by CalendarServer 16 Jul '09

16 Jul '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: sagen@… Type: Feature | Status: new Priority: 2: Expected | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by oxullo@…): Rahul, availability's lookup doesn't work due to a small bug: every mail should be stored in the directory record object (after being read from LDAP) with RFC2368 scheme. Please note that I had an issue with TB3b2+L1p2 (due to a Lightning's bug, filed as 435854 [https://bugzilla.mozilla.org/show_bug.cgi?id=435854 1]): whenever an user has a calendar with an empty inbox, Lightning starts to burst the server with polls. Can you tell me if you experience the same? I attach a patch which: * fixes availability lookup * fixes the support for resources and locations * adds the possibility to create delegation of resources and location via CalDAV compliant clients (like CalDAVClientLibrary) 1. https://bugzilla.mozilla.org/show_bug.cgi?id=435854 -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:27> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service
by CalendarServer 16 Jul '09

16 Jul '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: sagen@… Type: Feature | Status: new Priority: 2: Expected | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Changes (by wsanchez@…): * owner: wsanchez@… => sagen@… * priority: 3: Important => 2: Expected -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:26> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer-dev] [CalendarServer] #260: OpenLDAP directory service
by CalendarServer 16 Jul '09

16 Jul '09

#260: OpenLDAP directory service ---------------------------------------+------------------------------------ Reporter: jusiskin@… | Owner: wsanchez@… Type: Feature | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Other Keywords: | ---------------------------------------+------------------------------------ Comment(by rahul@…): Hi Aymeric, Firstly, thanks for the patch you have written. This is extremely standard based and should be able to integrate with any LDAP implementation using RFC2307bis schema. I highly recommend that this patch be merged with the main calendarserver trunk. Anyway, I have two queries reg. this patch. 1. Is it possible to do free-busy lookups? I have used OpenLDAP with TB 3.0beta2 + Lightning 1.0pre2. While inviting attendees, and adding them, the free-busy schedule is not shown? Is this a bug? Also is free-busy lookup the same as attendee lookup? 2. Does your code take into consideration primary group membership? Because from what I know, the gidNumber of the user object class represents the primary group of that user and all the groups which have the user's dn listed in their uniqueMember attribute are secondary groups. Looking forward to a response. Regards, Rahul. Replying to [comment:16 aymeric.augustin@…]: > Following up on my previous post... I just attached a new patch, with the code I am now running in production at several medium-sized companies. > > All necessary settings are now configurable (for example email addresses generation for groups) and caching is implemented (the web interface is 6x faster on my setup, which is fairly standard). > > Is it likely that this patch will be integrated into calendarserver, and would any additionnal work be necessary for this ? (more doc ?) -- Ticket URL: <http://trac.calendarserver.org/ticket/260#comment:25> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0