On May 6, 2009, at 10:10 AM, Helge Heß wrote:
Please elaborate. Whats the advantage of
ATTENDEE;[email protected]:urn:uid:98128912
over
ATTENDEE;X-CALSERVER-UID=98128912:mailto:[email protected]
or
ATTENDEE;DIR=urn:uid:98128912:mailto:[email protected]
Thats the core of my claim of 'no good reason'. Your requirements
can be met w/o breaking anything existing. (if this does break with
some client, please tell us which)
The advantage is that the primary value of the property corresponds
to the primary key on my server, and this is unlikely to break.
I'm not convinced that parking a GUID in DIR is a valid use of DIR,
nor that DIR is any safer than an X-parameter.
I'm not inclined to trust all clients to do the right thing
according to the spec. This apparently includes not assuming that the
value is an email address, per the spec, but I'm willing to live with
that if it keeps my primary keys intact.
Further, as I said, there is no way for a client to resolve a UID to
some contact record. You talk about a REPORT to resolve UIDs, I
suppose this might be OK. Whats this REPORT?
report_DAV__principal_property_search here:
http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/extensions.py
Though that may be reorganized in a bit. I'm guessing Cyrus will
write up a spec for that in a bit as well.
BTW1: using properties for lastname/firstname etc is rather useless,
since properties are not covered by etags, hence uncachable.
It's useless for caching, perhaps. That doesn't make it useless,
though it might make it worthless to you.
WebDAV has its flaws as regards properties and caching.
BTW2: a vCard URL would be nice. (doesn't even have to be CardDAV,
plain URL pointing to a vCard would be fine, similiar to FBURL)
Agreed.
Both of these (the parameters and the new REPORT) need to be
standardized for interoperability.
Well, yes, I also thought that we might want to standardize a UID
parameter to avoid an X-CALSERVER-UID. But then, this is basically
what DIR already provides.
_______________________________________________
calendarserver-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
