FYI. The message below is from some Apple folks that I know. One
on the client side and one on the server side.
I also received a response from one of the Oracle developers that
their "server does not allow PROPPATCH on principal resources
either. Calendar home or calendar collection are fine."
-------- Original Message --------
Hi Helge,
--On May 15, 2013 at 10:39:31 AM -0700 Helge Heß <helge_hess@apple.com>
wrote:
> I don't think it's a good idea even if some servers allow that (I mean
> it's a good idea in pure DAV theory, but it's not a good choice in
> practice ;-). Principals will be often mapped to some kind of
> authentication service (say LDAP) and such rarely provide arbitrary extra
> storage.
>
> My guess is that PROPPATCHing something into the home is probably going
> to work slightly better. But it's still not required and I would expect
> many servers to not support this (such where the home is not a real
> physical entity, but just an entry point into e.g. a DB).
>
> Yet another approach would be to just PUT a non-calendar resource with
> the config into the home. But again, this will only work in a few servers.
>
> One thing which would work universally for the client, is taking another
> URL (pattern) where the client can store config information. Then the
> admin of the backend server could decide where user configuration should
> go. (direct it to the principal, to the home or some other, regular DAV
> store).
>
> Summary: There is no interoperability on this :-/
Agreed. For the record our server does not support PROPPATCH of dead
properties on a principal resource. With our delegate support we do allow
PROPPATCH of group-member properties on the delegate resources which are
children of the principal.
I do think using WebDAV properties for preferences is not the best
solution. In Mulberry, as a replacement for IMSP and ACAP, I ended using a
simple WebDAV PUT of a properties document to a "regular" WebDAV server
(not that our calendar server does not support non-calendar/address data
puts in a home). The benefit of using a resource rather than properties is
that conflicts can be detected (etag conditions) - that is important
because multiple clients are involved. That said, it is still not ideal in
that it would be nice to be able to do partial updates - but PATCH could
take care of that.
In any case, I suggest telling the client folks to try PROPPATCH on
principals, if that fails, try the calendar home, if that fails try the
default calendar (which is not ideal because it could be deleted), if that
fails - fail gracefully!
--
Cyrus Daboo
_______________________________________________
tc-caldav-l mailing list
tc-caldav-l@lists.calconnect.org
http://lists.calconnect.org/mailman/listinfo/tc-caldav-l
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University