Isn't this working with webdav backend itself already?

Keith, any response for comment#1 ?

From the CardDav draft (http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-10) it looks like CardDav mainly adds some addressbook specific access control and search features. This IETF working group page describes the goals of the CardDav standard(http://datatracker.ietf.org/wg/vcarddav/charter/).

The author of the evolution WebDav addressbook plugin wrote this(http://www.go-evolution.org/Contacts_on_WebDAV): 

"What about (V)carddav? VCardDAV is a proposed extension to webdav which simplify storage of addressbooks on the server. It should be easy to extend the plugin to support carddav servers. However I'm not aware of any open source carddav server implementations at the moment. So I don't have any plans at the moment to work on this (but will happily accept patches)."


Several CardDav servers have been written since then(http://carddav.calconnect.org/implementations/servers.html)

Created attachment 210958 [details] [review]
(possible?) eds patch

for evolution-data-server;

Could you try with this change, please? My checkout of CalendarServer doesn't want to run, thus I cannot test it properly, but this change should at least provide UID to the server. The only thing is how much this breaks if you edit the just-added contact, or when deleting it, because the webdav backend sets UID to a URL of the contact, thus the editing will provide different UID for the same contact on the server. The DAViCal's adressbook implementation is not strict on UIDs as the CalendarServer is.

Keith: Is it possible that you try the patch in comment 4, in case you compile yourself?

Hi!

I'm the author of this project: http://code.google.com/p/sabredav, which is (among other things) a CardDAV server. It's also used in Owncloud and a whole bunch of other servers.

While I cannot confirm whether the patch is working, I can tell that the missing UID is indeed a bug from the perspective of CardDAV, and makes it incompatible with SabreDAV as well.

Would love to see this patch happen :)

Evert, I can create a test package for fedora with the patch included, or if you could guide me how to easily make the SabreDAV running (I seem to be slow on this kind of things), then I'll test it even myself. I noticed in the readme, that the test server is currently down.

Hi Milan!

Thanks for taking a look at this. If this is the easiest, I just created an account you should be able to use.

Server: https://dav.fruux.com/
username: evert+evotest@fruux.com
password: Ki26CrJpHh

Url to addressbook: https://dav.fruux.com/addressbooks/a3298285508/default/


If this is not helpful, I also have no problem installing fedora + your custom rpm. Let me know what I can do.

If you did test this, I would also love to know when I can disable that account again :)

Thanks for the test account, I was able to reproduce the error on new contact creation (it returned Bad Request), then I patched eds and tried again, and it worked as expected. I also tried to modify my contact and delete it, all worked as expected. You can delete the test account now, again, thank for it.

Created commit 28d8a94 in eds master (3.7.2+)
Created commit a540f31 in eds gnome-3-6 (3.6.2+)

Great to hear this! Looking forward to 3.6.2 :)