Re: [CalendarServer-changes] [1187] CalendarServer/trunk/twistedcaldav/directory/appleopendirectory.py
Is this code necessary? If we're ending up with multiple entries in the property, that should be fixed in the caller, not here. If this makes a performance difference, I guess OK, but it should be an exact match using ==, not a .find() call. -wsv On Feb 14, 2007, at 8:32 AM, source_changes@macosforge.org wrote:
Revision 1187 Author cdaboo@apple.com Date 2007-02-14 08:32:03 -0800 (Wed, 14 Feb 2007) Log Message
Ignore %(principaluri)s in calendar user address template as server automatically adds those. Modified Paths
CalendarServer/trunk/twistedcaldav/directory/appleopendirectory.py Diff
Modified: CalendarServer/trunk/twistedcaldav/directory/ appleopendirectory.py (1186 => 1187)
--- CalendarServer/trunk/twistedcaldav/directory/ appleopendirectory.py 2007-02-14 16:16:11 UTC (rev 1186) +++ CalendarServer/trunk/twistedcaldav/directory/ appleopendirectory.py 2007-02-14 16:32:03 UTC (rev 1187) @@ -304,6 +304,12 @@ # Now do substitutions result = set() for template in self.cuaddrtemplates: + + # Ignore %(principaluri)s templates as we already default to adding those + if template.find("%(principaluri)s") != -1: + continue + + # Loop over each host variant for scheme, hostname, port in self.hostvariants: for subs in subslist: # Add in host substitution values _______________________________________________ calendarserver-changes mailing list calendarserver-changes@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-changes
Hi Wilfredo, --On February 15, 2007 11:54:34 AM -0800 Wilfredo Sánchez Vega <wsanchez@wsanchez.net> wrote:
Is this code necessary? If we're ending up with multiple entries in the property, that should be fixed in the caller, not here.
If this makes a performance difference, I guess OK, but it should be an exact match using ==, not a .find() call.
I think we have three choices here: 1) Not default the server to inserting the principal URIs into the calendar-user-address-set by default. Instead require each directory service to do that. The appleopendirectory.py does that via the %(principaluri) (though I will have to do some work to actually make that work). The XML file should be hard-coded to add them itself. 2) Leave the default mechanism in place and remove %(principaluri) as an option for the OD schema on the basis that the server is always using that. 3) Leave the default as-is, but support %(principaluri) properly. In terms of performance, all of this stuff will end up in the property database - so the on-the-fly default mechanism won't be a problem. -- Cyrus Daboo
On Feb 15, 2007, at 12:37 PM, Cyrus Daboo wrote:
Hi Wilfredo,
--On February 15, 2007 11:54:34 AM -0800 Wilfredo Sánchez Vega <wsanchez@wsanchez.net
wrote:
Is this code necessary? If we're ending up with multiple entries in the property, that should be fixed in the caller, not here.
If this makes a performance difference, I guess OK, but it should be an exact match using ==, not a .find() call.
I think we have three choices here:
1) Not default the server to inserting the principal URIs into the calendar-user-address-set by default. Instead require each directory service to do that. The appleopendirectory.py does that via the % (principaluri) (though I will have to do some work to actually make that work). The XML file should be hard-coded to add them itself.
No, the server should accept principal URIs regardless of what the directory service tells us.
2) Leave the default mechanism in place and remove %(principaluri) as an option for the OD schema on the basis that the server is always using that.
I think we are looking at the OD data in different ways. I think the OD data is primarily a way to tell the *client* which principal URIs the server supports. It is not meant to be a way to configure the server. I think the server should support all of the address forms it can find appropriate data for, regardless of whether OD provides a template for it. I'm not certain, in fact, that having the user address templates in OD is a great idea in the first place. We may want to yank it unless we can come up with a reason why the client actually needs it there, as opposed to asking via CalDAV.
3) Leave the default as-is, but support %(principaluri) properly.
In terms of performance, all of this stuff will end up in the property database - so the on-the-fly default mechanism won't be a problem.
This is what I'd prefer, I think. Or it may simply be best to ignore the templates in OD altogether and simply populate all of the available address forms. -wsv
Hi Wilfredo, --On February 15, 2007 12:54:47 PM -0800 Wilfredo Sánchez Vega <wsanchez@wsanchez.net> wrote:
Or it may simply be best to ignore the templates in OD altogether and simply populate all of the available address forms.
That would be fine by me, but I would still like to have that done by the directory service (the parent class) rather than hard-coding at the point of property lookup. So we want the server to support for calendar user addresses: relative principal URI absolute principal URI (http/https depending on which is running) email address urn:uuid -- Cyrus Daboo
Hi Cyrus, --On February 15, 2007 4:00:45 PM -0500 Cyrus Daboo <cdaboo@apple.com> wrote:
That would be fine by me, but I would still like to have that done by the directory service (the parent class) rather than hard-coding at the point of property lookup.
Actually I take that back. The directory service does not per se know what the principal uri paths are, so that does need to be done by the principal resource. -- Cyrus Daboo
The principal URI should be done by the DAV resource, I think, because the directory service doesn't get to decide whether we use those or not. Same, I think for urn:uuid:GUID, since guids are required for all records and we should always accept those addresses, rather than leaving that up to the service. The directory service should get to extend the address list based on whatever additional information it can obtain. mailto:EMAIL would be an example of that. -wsv On Feb 15, 2007, at 1:00 PM, Cyrus Daboo wrote:
Hi Wilfredo,
--On February 15, 2007 12:54:47 PM -0800 Wilfredo Sánchez Vega <wsanchez@wsanchez.net
wrote:
Or it may simply be best to ignore the templates in OD altogether and simply populate all of the available address forms.
That would be fine by me, but I would still like to have that done by the directory service (the parent class) rather than hard-coding at the point of property lookup.
So we want the server to support for calendar user addresses:
relative principal URI absolute principal URI (http/https depending on which is running) email address urn:uuid
-- Cyrus Daboo
participants (2)
-
Cyrus Daboo
-
Wilfredo Sánchez Vega