Allow routes to specify an alternate controller class.

[inferiorhumanorgans]

Brings this more in line with traditional Rails routes. Also useful for implementing additional verbs like REPORT.

[chrisroberts]

Do you have a use case for using a different controller class?

[inferiorhumanorgans]

https://github.com/inferiorhumanorgans/meishi/blob/master/config/routes.rb

[chrisroberts]

Thanks!

[inferiorhumanorgans]

Yeah this is kinda nifty as it allows me to have a controller that implements the REPORT verb as needed (and also define CardDAV support for all requests).

[chrisroberts]

I have been seeing more and more usage of CardDAV lately. If your implementation is generic enough (not tied directly to Rails for example) it would be nice to see this as an addon gem, or even moved into dav4rack proper. It would make a nice place to start for CardDAV instead of all the wheel reinvention.

[inferiorhumanorgans]

Agreed that it wold be nice to not reinvent the wheel.

Right now I am making use of rails for a few reasons (migrations, activerecord, having a web based user management tool). So I'm unsure how this would work as an addon, as I don't know what there is to configure or how generic it is (or could be). And as a Rack based Rails+dav4rack app it's already pretty easy to deploy.

As far as merging CardDAV support back into dav4rack, that's a definite possibility. But then there're the questions of:

• Do you want dav4rack to be generic or bog it down with more implementation specific details?
• Do you want dav4rack to have a dependency on ActiveRecord (or any database really)?

For now my goal is to make use of as much generic code as possible and push that down into dav4rack... but I do have a strong preference for using an SQL database because that will hopefully make some of the access control and reports easier.

[chrisroberts]

Well, this it has a lot to do with dav4rack growing out of its original intention. The included FileResource was really included merely as an example of how a resource could be built, with the expectation that the user would be building their own resource to use (even if it was subclassing out the FileResource). But with lots of patches coming in and with myself finally integrating in the litmus and running it against the FileResource, it is becoming a true and proper Resource.

Already in master is a mongo resource, and I am expecting to be adding in an S3 and cloud files resource soon. These will likely end up falling into a 'contrib' directory that users can optionally use. These contrib resources may have dependencies that they require, but they will not be specified as an explicit dependency within the dav4rack gem itself.

As far as activerecord/rails integration, I would like to keep things as framework agnostic as possible. However, providing a carddav controller/resource that is simply a shell (interface) for others to base off of would not be a bad thing. And having a fuller implementation either via gem or 'contrib' that actually makes use of rails/activerecord would likely be useful for others.

But this is big picture and really only if you have the time and motivation. It would certainly be useful to many I'm sure. Thanks so much for the contributions you've been making and making dav4rack better.

[inferiorhumanorgans]

Ah, for now the CardDAV bits are a bit bigger than say the mongo backend. The CardDAV standard requires TLS support and some sort of authentication all of which seem perfectly reasonable to shove into a (for example) sqlite database.

If you want to take a look and let me know how you might split that up so it's small (and generic) enough to include in dav4rack that'd be great. Keeping the resources and controllers in dav4rack with the DB classes + web front end in a separate app would work for me, but it's need to be in a relatively clean manner.

I'm really not sure what would be considered best practice here in terms of app distribution, so.