Hey Cyrus, Works like a charm...much nicer than the alternative. Is it reasonable to assume that there is no significance to the order the addresses are defined in the accounts.xml file, and in the calendar-user-address-set PROPFIND response?
It is becoming apparent that even the thinnest of clients needs to be able to persist configuration, and that the property queries at startup are more to discover changes in configuration than to discover the essence of their being. Thanks for the help. Regards, Mark On 11/25/08 11:55 AM, "Cyrus Daboo" <[EMAIL PROTECTED]> wrote: > Hi Mark, > > --On November 25, 2008 12:41:18 AM -0500 Mark Cockfield > <[EMAIL PROTECTED]> wrote: > >> The norm seems to be to use an email address, how do people handle the >> case where a calendar user's email address changes? It seems to me that >> every calendar object in the repository where the user is an organizer or >> an attendee would have to be updated. If I understand the specs correctly >> you could use a urn scheme except that iMIP requires a mailto. > > Typically in an organization when a user's email address changes what often > happens is that they end up with two addresses: the new one and the old > one, with the new one being the "preferred" one. This is to ensure that for > some period of time the old email address will continue to work (e.g. when > replying to email addresses composed with the old address). > > The calendar server does support multiple calendar user addresses and so, > in the above scenario, no changes would be needed if the old and new email > addresses are setup properly. > > That said, there are situations where maintaining the old address is not > feasible, and in that case something will need to be done. We have already > discussed the idea of have the server re-write calendar data on the way > into and out of the calendar store. We would change all mailto addresses to > urn:uuid on the way in (client PUT), and change them back to the (current) > mailto on the way out (client GET). That way the client always sees the > most up to date address. There are several problems with this - in > particular the need to force all clients to refresh their cached data when > an address does change - that will require some clever ETag invalidation > process. > > For now though, the best option is to maintain the old and new email > addresses. _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
