CardDAV extension

[schmurfy]

I am working on implementing carddav support on top of dav4rack and was wondering if a carddav implementation would be accepted as a pull request.

I suppose it could be done in an external gem but I think it makes a lot of sense to have it directly into dav4rack, what do you think ?

PS: and yes I saw meishi but I need a modular library not a fully functional rails application, I tried to base my work on it but in the end I feel like I am going to rewrite most of it.

[chrisroberts]

Hi. I'm always happy to include resource extensions so long as they provide specs to test them so they don't inadvertently regress as I'm working on the core. I would ask that you target the current development so you don't run into breaking changes soon. I currently have a few more litmus bits to work through before it's ready to release and that has just been a time issue. If you run into any issues, please don't hesitate to ping me.

[chrisroberts]

I cleaned up the branches as well. All the new work is isolated in the 0.3.0-dev branch so that would be the place to target. And thanks for helping to make dav4rack better!

[schmurfy]

The core sure needs some work ;) I am currently working on top of master, I will have a look at your dev branch.

[schmurfy]

I just tried your branch but a lot of tests fail, are they supposed to pass ? (I am testing your branch directly without my changes)

[chrisroberts]

Yes, a portion of the handler spec is currently broken due to implementation modifications to pass the litmus tests. The spec tests will be updated once the litmus has been passed.

For what it's worth, you can run the litmus tests using:

$ bundle install
$ bundle exec test/script.sh

[schmurfy]

ok, I wish there was a recognized litmus equivalent for carddav :/ During my previous work on dav4rack I relied entirely on litmus for the tests.

[schmurfy]

How much are you attached to 1.8 compatibility ? This is such a pain not to be able 1.9 features to support a version wich should already dead and buried by now.

[chrisroberts]

1.8 compatibility in the carddav resource itself, or the entirety of dav4rack? While I am tired of 1.8, there is still a large population using it with no clear upgrade path. I don't want to isolate developers from this library where they may not have the option or authority to bump the ruby version they are targeting. That said, with regards to the carddav resource, I have no problems with it being 1.9 only. I could probably be swayed making dav4rack require 1.9 or greater pretty easily, but I would like to keep the support for as long as possible.

[schmurfy]

ok, looks fine to me I will stay with 1.9 for the carddav part then which means I can use 1.9 in carddav tests too since they won't be executed when running in 1.8.

[schmurfy]

There is also the dependencies issue, carddav will pull some of its own which will be of no use to the core. I think I will end up releasing it as a separate gem this way I won't pollute the dependencies and can make clear 1.8 is not supported without confusing dav4rack users.

[schmurfy]

The project is advancing quite well, I am at a point where I can talk to iOS and Apple Contacts fairly well, my plans are for now to have carddav support but it should be soon followed by caldav support when I need it. When it make sense I try to add things into dav4rack (like my previous micro pull request ;)) instead of overwriting everything and there is one other thing which cardav/caldav both need and is (RFC speaking) part of the WebDAV standard: the REPORT method (part of the versioning extension).

What was done for meishi is to add a way in dav4rack to use another controller class, while it works I would prefer finding a way to add support directly into dav4rack even if not used by the core (yet :) ), what do you think ? I think I can add a generic way to add support for it into dav4rack but only if you are willing to merge it.

To give you a better idea here is the meishi implementation of the REPORT command: https://github.com/inferiorhumanorgans/meishi/blob/master/app/controllers/carddav/address_book_controller.rb

PS: I will release the gem on github under the MIT license but I want to stabilize the internals before that.

[schmurfy]

@chrisroberts what do you think about this ?

[chrisroberts]

@schmurfy I would definitely be willing to merge it in. The report bit looks easy enough to abstract out and likely let the resources provide any extra/custom functionality.

[schmurfy]

yes that is also what I think, I will give it a try.

[schmurfy]

First version of the gem is available here: https://github.com/schmurfy/dav4rack_ext There are still things I want to tweak but it works well with ios 5/6 and OS X 10.8 Contacts. I also translated a decent part of the relevant rfcs into specs.

[chrisroberts]

@schmurfy This is awesome! I'm going to work on cutting a new 0.3.0 release by early next week. I was trying to have full litmus passage by the time 0.3.0 hit but I might just bag it and do patch releases as each new chunk of litmus is passed up to 0.4.0.

[schmurfy]

I tried to implement a modular report system into dav4rack but I have some problems... The main problem is that a lot of helpers defined into the controllers are required to build the report (the multistatus response), I moved them into a shared module included in both the controller and the resource but after that I hit another wall: other methods are required and those access the rack env (env) to build their results (http_version).

I have had a lot of problem from the first time I looked at dav4rack with what appears to be a completely arbitrary separation between the resource and the controller, I consider them both to be controllers, what do you think ?

Do you have any idea how I could integrate support for the REPORT verb into the Dav4Rack controller to allow resources to generate their reports ? The problem is that the resource is the one that knows whether or not a report is supported and is also the only one able to generate it but the controller is the one with the tools to generate that response :/