I’m using InfCloud, it has support for events, tasks and contacts so it pairs perfectly with Radicale (which is also what I use). It doesn’t look amazing I’ll be honest and it lacks some features but it works fine.
Here’s my docker compose:
services:
infcloud:
image: ckulka/infcloud:0.13.1
container_name: infcloud
depends_on:
- php
ports:
- "5233:80/tcp"
volumes:
- "infcloud:/usr/share/nginx/infcloud"
- "./data/config.js:/usr/share/nginx/infcloud/config.js:ro"
restart: always
php:
image: php:7.3-fpm-alpine
container_name: infcloud-php
volumes:
- "infcloud:/usr/share/nginx/infcloud:ro"
restart: always
volumes:
infcloud:
Run it without mapping config.js first and copy it from the container, edit it on the host, then map the volume and reprovision the container. You have to find the section globalNetworkCheckSettings and add a href: entry that points to your radicale host, for example href: "http://192.168.1.1:5232".
Another essential setting is to edit the Radicale config file and add the following section:
[headers]
Access-Control-Allow-Origin = http://192.168.1.1:5233
Access-Control-Allow-Methods = GET, POST, OPTIONS, PROPFIND, PROPPATCH, REPORT, PUT, MOVE, DELETE, LOCK, UNLOCK
Access-Control-Allow-Headers = User-Agent, Authorization, Content-type, Depth, If-match, If-None-Match, Lock-Token, Timeout, Destination, Overwrite, Prefer, X
Access-Control-Expose-Headers = Etag, Preference-Applied
The -Allow-Origin host and port must match the URL where you access InfCloud in the browser.
If you use a reverse proxy and you put Radicale / InfCloud behind domain names you can use the domain names in config.js and config. As long as InfCloud knows where to find Radicale, and Radicale knows where InfCloud comes.
You should consider if you really want to integrate your application super tightly with the HTTP protocol.
Will it always be used exclusively over a REST-ful HTTP API that you control, and it has exactly one hop to the client, or passes through hops that can be trusted to never alter the HTTP metadata significantly? In that case you can afford to make HTTP codes semantically relevant for your app.
But maybe you need to pass data through multiple different types of layers and different mechanisms (socket protocols, pub-sub, file storage etc.) In that case you want all your semantics to be independent from any form of transport.