nextcloud / nextcloud/server

Allow for higher sync rate for subsciption calendars

Open
#46,171 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

1. to develop enhancement feature: caldav
Dominant language
PHP
Stars
36.9k
Forks
5.2k
Avg merge
2d 3h
Merged PRs (30d)
713

Description

@tcitworld wrote:

The Nextcloud server caches the subscriptions (stores data in the database) and exposes them as regular calendars. The default refresh rate for this is of one week, which is appropriate for things like public holiday calendars, but might not be for other things, for instance subscribing to a public calendar from another Nextcloud user, and expecting real-time sync.

This high refresh rate makes sense because on servers with a lot of users and subscriptions, the cron would keep wasting time refreshing calendars for nothing, and there could be a risk of the subscription source blocking the server's IP. For instance, as subscriptions can't be shared (or provided by the admin), if all 10 000 users from a company need to subscribe to the holiday calendar from their local government, that's 10 000 requests you need to make every X minutes/hours/days when the original calendar data only changes once or twice a year.

Nextcloud supports properties available for the subscription source to tell what's the appropriate refresh rate (X-PUBLISHED-TTL, REFRESH-INTERVAL), but in practice no-one provides them.

I think there's an issue about providing the setting to select an appropriate refreshment rate for each subscription to end-users in calendar, which would kinda solve most of the issue, though there's a risk users could abuse it, so a minimal rate setting for the admin would be nice as well. In any case, that's not the current state.

So on the other hand, clients have no issue with refreshing the local subscription every 15 minutes/hour/day or even each time the app is opened, as it's only doing it for a single user and from a dedicated IP address.

Therefore, people who would have been forced to manually add the subscription on their device before this change and will now just used the exposed subscriptions from the NC server may have the impression that subscriptions don't get updated when they expect it.


We should take a delta of calendar events and only update those events that have changed.

We should also update all calendars that have the same subscription URI (ex: holiday calendars) at the same time so we only need one run for these calendars.

Work packages

Follow-ups

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with apps/dav/lib/CalDAV/WebcalCaching/RefreshWebcalService.php, especially the subscription refresh logic referenced in the issue, and review the linked work packages and follow-up issue. Done means supporting a higher appropriate refresh rate, updating only changed events, and refreshing calendars with the same subscription URI together.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.