Handle autorefresh and/or refreshing and reload of CalDAV calendars

RESOLVED DUPLICATE of bug 389397

Status

Calendar
Provider: CalDAV
RESOLVED DUPLICATE of bug 389397
11 years ago
10 years ago

People

(Reporter: lionel valero, Unassigned)

Tracking

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

under Lightning 0.3/sunbird 0.3 the "reload remote calendar" for a caldav calendar does not work, actually there is no network traffic generated by this command between the client and the caldav server, contrary to an icalendar calendar (ics).

Reproducible: Always
(Reporter)

Updated

11 years ago
Version: unspecified → Lightning 0.3
The lack of "reload" for CalDAV was intentional.

In theory, Sb/Ln should keep itself up to date with changes from external applications by checking etags.  Unfortunately, that piece isn't complete yet.

I defer to dmose on whether or not we want to add this.
Component: General → Provider: CalDav
OS: Windows XP → All
QA Contact: general → caldav-provider
Hardware: PC → All
Summary: caldav reload remote calendar → "Reload remote calendar" is disabled for CalDAV calendars
(Reporter)

Comment 2

11 years ago
Actually in the nightly build version of Sb the feature is not available for a caldav calendar.
Yes, "Reload" is disabled for CalDAV calendars in all Sunbird and Lightning builds.

Comment 4

11 years ago
can we close this issue? not sure if this is still valid
Whiteboard: [qa discussion needed]

Comment 5

11 years ago
For my part, I'd like to see this remain open. The ability to (auto)reload is important for shared calendars, such as resources or even owner/assistant in our small-business audience. Calendar sharing is/should be one of the strengths of CalDAV.

I see the etag issue mentioned in comment #1 differently. Etags will prevent 'lost update' problems where users sharing a calendar inadvertently overwrite each other's changes. But currently if two users are sharing a CalDAV calendar and user A adds/deletes/changes an item, mozcal will not display that fact to user B until user B restarts or changes view. I see this bug as addressing the latter issue.
jminta and/or dmose:
Regarding Bruno's comment #4, should we allow auto-reload for CalDAV calendars?
Whiteboard: [qa discussion needed]
Version: Lightning 0.3 → Trunk

Comment 7

10 years ago
Marking this as confirmed and changing the summary to reflect more the intent of this bug: That we need to handle refreshing properly in our CalDav provider.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: "Reload remote calendar" is disabled for CalDAV calendars → Handle autorefresh and/or refreshing and reload of CalDAV calendars

Updated

10 years ago
Keywords: relnote

Comment 8

10 years ago
For 0.5 release notes: happens more with BedeWork CalDav than Cosmo. So, the level of disturbance to the user might be related to the implementation of the CalDav server.

Comment 9

10 years ago
(In reply to comment #8)
> For 0.5 release notes: happens more with BedeWork CalDav than Cosmo. So, the
> level of disturbance to the user might be related to the implementation of the
> CalDav server.

same problem with RSCDS 0.8.0 - automatic updates of new or deleted entries do not work. In my eyes updating is very important for a multiuser calendar environment.


IMO duplicate to bug 389397.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 389397

Comment 11

10 years ago
Jörg, could you give more details? I'm using RSCDS 0.8.0 with a recent 1_8 build, and updates set to happen every one minute. Changes, deletions and additions all seem to work fine. Changes in Lightning 0.5 on one machine are picked up on another hosting the build after a delay of up to 1 minute. 

There does seem to be a problem with updates to the "All Events" list in Sunbird with RSCDS 0.8.0 . Caused by creating a new event? The number of items stays the same, but the last two in some pattern I've not determined change to the new event and to each other, IYSWIM. Three events in two spaces.

Shame the items are all redrawn even when none of them have changed. But that's another bug, I guess.

Comment 12

10 years ago
Even though refreshes are now implemented, this is different from 389397. That, I think, though I'm a bit hazy about it and will review on Monday, is about getting providers to act as if they've just been loaded when used via the composite provider. CalDAV is capable of more efficient refreshes using etags, date-ranged queries, etc. But perhaps that should be a RFE given refreshes now work.

BTW, if the solution of bug A fixes bug B, is B always considered a duplicate?

Comment 13

10 years ago
(In reply to comment #12)
> Even though refreshes are now implemented, this is different from 389397. That,
> I think, though I'm a bit hazy about it and will review on Monday, is about
> getting providers to act as if they've just been loaded when used via the
> composite provider. CalDAV is capable of more efficient refreshes using etags,
> date-ranged queries, etc. But perhaps that should be a RFE given refreshes now
> work.

As I see it, there are two separate issues here:
1) The CalDAV provider is insanely chatty on the wire, refetching calendar-data on every view change etc. This problem is exacerbated by having autorefresh implemented. We need to do better, presumably by first fetching etags and then fetching only deltas.
2) autorefresh

This bug, as stated, is about #2, so I think that duping it is proper. I had kind of figured to fix #1 first, but that's not really necessary. #1 has never been filed as a bug or RFE, to my knowledge. Fixing it in a reasonable fashion will, I think, require server-side support for CalDAV:calendar-multiget queries, which is not yet present in all the server implementations we'd like to maintain interop with, including IIRC RSCDS.

Comment 14

10 years ago
AIUI, there is a phase in the DAV negotiation process when one can obtain information about the capabilities of a server ("OPTIONS", IIRC). Sorry, no, just checked this: RFC4791 S5.1.1 only specifies that a client can be informed calendaring is supported (by the DAV HTTP header including the string "calendar-access")

This looks more useful: RFC4791 S2 says that servers
"MUST advertise support on all calendar collections and calendar object resources for the calendaring reports in the DAV:supported-report-set property, as defined in Versioning Extensions to WebDAV [RFC3253]." 

Could this be used to test if calendar-multiget REPORTs are supported? I cant find much information about D:supported-report/D:supported-report-set. But if so, we could check this (otherwise something else, like trying it?) and fall back to the noisier way if there's no support.

BTW, I spoke to the author of RSCDS and he said that calendar-multiget is implemented in the GIT version (I didn't have logging turned on, sadly, and haven't found an IRC log for the channel on the web). Presumably this means it'll be in v0.9.0

This is it being added here:
http://git.catalyst.net.nz/gw?p=rscds.git;a=history;f=inc/caldav-REPORT-multiget.php;h=edd4fffae398ae70ac616030fd9505443460a8f7;hb=HEAD

I'll file an RFE ("CalDAV provider module could cause less network traffic"?) with this information if I can't find one.

Updated

10 years ago
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.