OK,
rereading the thread it sounds like you refuse to fix it. I guess
there is little we can do about it besides filing bug reports listing
Lightning, Evolution, Kontact, ... interoperability issues :-)
So lets focus on how a client can resolve the 'Apple way' GUIDs and
how all that works internally.
a) if a client PUTs a message with attendees like that:
ATTENDEE:mailto:a...@def.de
CalServer will lookup the mailto in its directory and replace
it with:
ATTENDEE;x-calendar-server-email=...@def.de:urn:uuid:29382..
The server will do this instantly and the client needs to do
a GET after each PUT.
a1) Question: what happens if the mailto is not in the local
directory, but points to an external participant?
(eg comes from a CardDAV server)
a2) Can you return modified content in the PUT response, with a
200 OK instead of requiring a reGET? (not sure whether that
would be OK will HTTP)
b) if a client PUTs a message with an attendee and a GUID like that:
ATTENDEE:urn:uuid:98283...
The UUID is not a CalServer one, its created by the client (or
some other server).
What will happen with that, stored as-is?
c) you mention that there will be an Apple specific REPORT to
retrieve information about GUID attendees.
To avoid additional HTTP IO, can we have it that way:
<?xml version="1.0"?>
<C:calendar-multiget xmlns="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav"
xmlns:A="http://calendarserver.org/ns/";>
<prop>
<getetag/><getcontenttype/>
<C:calendar-data/>
<A:attendee-info>
<A:uuid/>
<D:principal-URL/>
<D:displayname/>
<D:email/>
</A:attendee-info>
</prop>
</C:calendar-multiget>
Or something similiar. Core point is, that the required info
can be retrieved in one step (simple GETs become useless ...)
Thanks,
Helge
... still hoping that there will be an option to make the server do it
the X-APPLE-UUID way.
--
http://zideone.com/
_______________________________________________
calendarserver-dev mailing list
calendarserver-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-dev
