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