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 <[EMAIL PROTECTED]
> 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
_______________________________________________
calendarserver-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/calendarserver-dev
