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 -------- Subject: Re: [Tc-caldav-l] PROPPATCH on principal resources Date: Wed, 15 May 2013 14:16:13 -0400 From: Cyrus Daboo cyrus@daboo.name To: Helge Heß helge_hess@apple.com, tc-caldav-l Reflector tc-caldav-l tc-caldav-l@calconnect.org
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!
Hi Ken,
OK, we will change the PROPPATCH destination in future (or will add an option and then you can specify any destination). I will release the next version of CalDavZAP (0.9.0) very soon - the PROPPATCH change/fix will be added in the 0.9.1 or 0.10.0.
JM
On May 17, 2013, at 9:33 PM, Ken Murchison murch@andrew.cmu.edu wrote:
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 -------- Subject: Re: [Tc-caldav-l] PROPPATCH on principal resources Date: Wed, 15 May 2013 14:16:13 -0400 From: Cyrus Daboo cyrus@daboo.name To: Helge Heß helge_hess@apple.com, tc-caldav-l Reflector tc-caldav-l tc-caldav-l@calconnect.org
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
-
Ján Máté -
Ken Murchison