Another question concerning migration from OC x classic to OCIS: from my understanding, after reading
it should be possible with OCIS 4.x to migrate calendar/caldav and adressbook/carddav data from a OC classic instance to an OCIS instance, as the required services and APIs are already present. Is there any other relevant information source for this?
i don’t think that WebDAV support automatically means that calendar (via CalDAV) and contacts (via CardDAV) support is automatically given. And i think i have also found nothing about such a support at the two linked articles.
I had asked the ownCloud people about such an integration already here:
the whole webdav stuff was already functional in previous releases, only the webdav endpoints have changed a bit.
I think the general problem is that we have a very detailed (and good!) documentation of every OCIS service but a lack of somehow “simpler” migration docs targeting the move from “OC classic” (10) to “OC cloud-native” (OCIS). That would help people who do no want to “emigrate” to Nextcloud now (like me ).
i think there is still confusion about the differences between WebDAV and CalDAV/CardDAV. From what i know CalDAV/CardDAV are an extension to WebDAV and this doesn’t mean that if WebDAV support is there then you will also automatically get CalDAV or CardDAV support in the backend (i think this would need to be separately implemented by the ownCloud people).
Maybe @butonic, who wrote the reply on reddit, can comment this. I think that the necessary functionality is already there, but I have no idea how to test it or to migrate the old cal/carddav data to the new server environment …
As another user wrote previously, there is an impressive bunch of developer documentation for all OCIS services. But nearly nothing targeting a simple migration from the old PHP/LAMP to the new GOlang/cloud-native world …
i have checked the reddit thread and i can’t find any single mention of calendar, contacts, carddav or carddav within it. So i think that if there is WebDAV support i can’t be automatically assumed that such support is there as outlined previously:
Aren’t they kind of self-explanatory? I know their absence has left me unwilling to invest time in testing OCIS. My ownCloud address book and calendars have been my authoritative datastores for at least a decade now.
If you are wondering whether web access is necessary, I would say yes. Even though I use client applications like Kontact, Thunderbird, and DAVx⁵ most of the time, sometimes the web access is necessary or convenient.
Holger, I know that webdav is not caldav/carddav ;-). The typical use cases are already supported in OC classic, therefore the missing functionality in OCIS is a severe functional regression, at least for smaller installations. The core use cases:
Calendar: sync of caldav calendar data between desktop clients (e.g. Thunderbird), mobile clients (e.g. davx5) and a central storage (OCIS)
Adressbook/carddav: same use cases and same example clients.
We would certainly need service auto-discovery of the storage endpoints for the clients
if possible, the caldav/carddav storage should also be available for spaces. This would help to create “group calendars” and shared (but still “save”) addressbooks. But this should be reviewed from the GDPR view point, especially for address/contact data …
From my point of view, the core functionality in all cases should be the storage and the sync process, not any fancy UI (“nice to have”, but not essential). Thus the web UI from the old OC 10 calendar app is not important, for two reasons:
people typically handle their adressbooks and calendar data inside of specialized apps (e.g. Thunderbird, MS Teams, mobile adressbooks and calendars etc.), but not on a “web site”.
there are already enough UIs present on the client side.
for me this is also a must have…
i use contacts and calendars and tasks on a daily basis - and all is synced over my owncloud…
i think at the begining of OCIS tehre was a mentioning that it is better to us other backend servers for this - as it is not the main focus (that is only files) -
i did not remember exactly… i think it was mentioned that an external service / server that also can do the user login things can also handle the card + cal DAV things…
Same use case here and I assume, its the same situation with most smaller installations that did not yet switch from ownCloud to Nexcloud. Some time ago, owncloud GmbH played with kopano to provide caldav/carddav, as I remember.
I totally agree with the “enterprise” and “file-sharing” focus of ownCloud versus the more general “we solve all problems in one interface” strategy of the Nextcloud guys (in german “Gemischtwarenladen”). The architecture switch from ownCloud classic (LAMP architecture) to OCIS (cloud-native) was the right decision, as scalability and “cloud friendliness” are critical points for any file sharing services.
But, there still should be an option to integrate core functionalities for caldav/carddav somehow. I would really prefer to have either
some native go micro-service for caldav/cardav directly in the ocis binary
From a private view, I can only confirm that I like using radicale. Been using it for months now, and I haven’t had any complaints from my own friends, customers or with incoming appointments. Haven’t tested it with Apple or Windows devices, though. Personally, I like radicale and the one purpose, one tool approach.
Yes, I am totally aware of that. But sadly no other tool served my needs. Hope dies last, but it dies, I guess. When I started using it, the last change was merely 3 or four months old. Sad, since it works. I hope it does not become an orphan.
… that sounds cool, should be worth a try. But maybe @dragotin and others can also have a look at the go-webdav library I mentioned earlier. I am not familiar with the whole OCIS code, but:
From a “KISS principle” architectural perspective it sounds more “straightforward” to integrate a caldav/carddav lib into the golang codebase for adding caldav/carddav calls, instead of adding an auth layer into an external app of different architecture (python).