Using Vikunja as a caldav client about vikunja

[SamirSaidani]

I think that writing a caldav server is harder than writing a caldav client, for the same reason that building an api is harder than just using it.

About vikunja/sabredav, it's like php/mysql: they don't use the same language, but I can imagine building a dockerized container with both server. If vinkunja is a caldav client able to sync with any caldav server, then it's pretty easy to install a compatible caldav server alongside with vikunja. For instance, it's super easy with cloudron. Anyway, my proposal would be to not care about this aspect: the idea would be just to let the vikunja admin be able to setup the caldav server in vikunja settings, like it is the case for any caldav client.

On how to build a caldav client, there is a bunch of caldav libraries out there, in go, dart, or javascript, e.g:
https://github.com/emersion/go-webdav
https://github.com/julisanchez/caldav_client
https://github.com/nextcloud/cdav-library

I don't know which one would fit your needs, and there is probably others libraries, but I think that it would be definitely easier to start from an existing caldav library client in the language of your choice instead of rebuilding a caldav server from scratch.

Hope it helps !

[kolaente]

Please, don't remove caldav server/api from Vikunja backend. I am using Vikunja as todo/planning tool. And it is super handy to have an option to sync tasks with DAVx5 and jtxBoard.
I think cladav server should be only removed once an Android client for Vikunja is released. Otherwise you don't have really any options to set up notifications/reminders for tasks in Vikunja on your android phone. Setting up mail server (in case of self-hosting) for reminders is quite hard.

It's not planned to remove the caldav server functionality from Vikunja.

[kolaente]

I agree building a fully working caldav server is a lot of work and hard to get right - you can see this very well in the current caldav implementation which does not really work properly.

It's not really possible to integrate either sabredav or radicale "just like that" into Vikunja because both are written in other programming languages than Go. A possible way would be to build something with one of those tools which translates caldav calls into Vikunja API calls and just proxies requests between caldav clients and the Vikunja API.

I would love to have a caldav import at some point, similar to the other importers we have right now (Trello, Todoist, ...). That could extended into some kind of sync thing in a second step. I'm just not sure if it really is easier to implement a full-blown caldav client that it is to implement a caldav server.

I'm all open for suggestions on how to build this.

[kolaente]

Just to make sure I understand you correctly: Do you want to use the Vikunja Frontend with any caldav server or do you want to import/sync tasks from a caldav server into your Vikunja instance? The latter one is somewhat possible, the former is pretty much out of scope for the project.

[SamirSaidani]

To be specific, I'd like to use the nextcloud sabredav-based caldav server with Vikunja. Either as a front-end or by syncing tasks. I think that it would be easier for vikunja to be just a front-end caldav client instead of a full-fletged caldav server supporting two-way sync. Check for instance 2do for Mac OS which is a great caldav client (unfortunately closed source).

[kolaente]

Thanks for the clarification. It might be easier to implement a caldav client without an api layer in between, however we already have the api layer for Vikunja. Replacing that with a caldav-only client would be a lot of work and result in less features than what Vikunja currently has (Caldav does not have share links or kanban, for example).

Therefore, I don't see Vikunja becoming a fully-fledged caldav client any time soon. However, I see how having functionality within Vikunja to connect to other caldav servers would be useful. I think the best way to achieve this would be to first build a migrator from caldav to Vikunja (similar to the other ones like trello) and then in a second step build a sync mechanism so that Vikunja can update tasks in a remote caldav server. Both of these would still require a Vikunja api server running somewhere so I'm not entirely sure if that's what you want.

[SamirSaidani]

Thanks for taking into account my request, I really appreciate :-)

I understand that the api layer seems to be a problem to make vikunja a caldav client. I'm curious to understand why it would be easier to code an api able to migrate or sync with a caldav server vs an api able to get and push information (crud-like) to a caldav server ? It seems to me that if you are able to sync, then you need first to code an api able to act as a caldav client, since syncing feature is a superset of caldav client features ?

I'm ok with an api server, I guess that it's a kind of an api-bridge between a caldav server and the vikunja core api ?

As far as I'm concerned, just a migrator would be useless for me since it would break my actual workflow: I won't be able to use a android caldav client anymore (tasks, 2do, etc).

Maybe we can get some inspiration with Etesync or DecSync approach - cf DecSync cross-platform library, Etesync caldav adapter or the decsync-radicale plugin, though I don't know how it would fit with the vikunja approach:

DecSync allows for decentralized synchronization of calendar/contacts. You can run a localhost (i.e. not port-forwarded or even discoverable locally) Radicale server, that only runs when the client computer does, and is only accessible from the computer it runs on. Radicale syncs to Thunderbird or Evolution, and this plugin syncs Radicale to a folder, which can be synced with Syncthing to other devices. This way you have a copy of all data on all devices, and any device can accomplish synchronization, not just the server.
src: 39aldo39/Radicale-DecSync#13

[kolaente]

The main reason is we already have the api. The Vikunja frontend is designed to work with Vikunja's api. Changing that in the frontend would require a lot of work once and afterwards to maintain it. Hence, it would be easier to fetch the tasks from an external caldav server and put them into Vikunja in the format it (and the clients) can already understand. Pushing changes back to the caldav client would "translate" the tasks from Vikunja back to the caldav server.
For a migrator there's already parts in Vikunja to build it upon which would make that part easier than a rewrite of the frontend.

As far as I'm concerned, just a migrator would be useless for me since it would break my actual workflow: I won't be able to use a android caldav client anymore (tasks, 2do, etc).

Have you tried using the caldav integration of Vikunja?

Maybe we can get some inspiration with Etesync or DecSync approach - cf DecSync cross-platform library, Etesync caldav adapter or the decsync-radicale plugin, though I don't know how it would fit with the vikunja approach:

If you only want to run VIkunja on your computer, you theoretically can. You will still need to run the api somewhere, but you can do that on your computer as well, next to the desktop app.

[SamirSaidani]

As far as I'm concerned, just a migrator would be useless for me since it would break my actual workflow: I won't be able to use a android caldav client anymore (tasks, 2do, etc).

Have you tried using the caldav integration of Vikunja?

I didn't: I've understood that vikunja caldav integration is at a early stage and alpha, I don't want to take the risk to lose critical professional data. I prefer to rely on a battle-field tested caldav server for professional use.

[kolaente]

I didn't: I've understood that vikunja caldav integration is at a early stage and alpha, I don't want to take the risk to lose critical professional data. I prefer to rely on a battle-field tested caldav server for professional use.

As always - no backup, no pity. I understand you don't want to put critical data in there but please check if maybe the caldav integration already does what you want. You don't need to switch everything at once, maybe just try it with one little project?

[young-druid]

Please, don't remove caldav server/api from Vikunja backend. I am using Vikunja as todo/planning tool. And it is super handy to have an option to sync tasks with DAVx5 and jtxBoard.
I think cladav server should be only removed once an Android client for Vikunja is released. Otherwise you don't have really any options to set up notifications/reminders for tasks in Vikunja on your android phone. Setting up mail server (in case of self-hosting) for reminders is quite hard.