[CalendarServer-dev] Re: [CalendarServer-changes] [1187] CalendarServer/trunk/twistedcaldav/directory/appleopendirectory.py

[Wilfredo Sánchez Vega]

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 at 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