361520 - Handle autorefresh and/or refreshing and reload of CalDAV calendars

Status: RESOLVED DUPLICATE of bug 389397

(Calendar :: Provider: CalDAV, defect)

Description

[lionel valero]

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

Comment 1

[Matthew (lilmatt) Willis]

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.

Comment 2

[lionel valero]

Actually in the nightly build version of Sb the feature is not available for a caldav calendar.

Comment 3

[Matthew (lilmatt) Willis]

Yes, "Reload" is disabled for CalDAV calendars in all Sunbird and Lightning builds.

Comment 4

[Damian Szczepanik]

can we close this issue? not sure if this is still valid

Comment 5

[Bruno Browning]

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.

Comment 6

[Matthew (lilmatt) Willis]

jminta and/or dmose:
Regarding Bruno's comment #4, should we allow auto-reload for CalDAV calendars?

Comment 7

[cmtalbert]

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.

Comment 8

[cmtalbert]

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

[Jörg Raftopoulos]

(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.

Comment 10

[Daniel Boelzle [:dbo]]

IMO duplicate to bug 389397.

Comment 11

[russell-bugzilla]

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

[russell-bugzilla]

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

[Bruno Browning]

(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

[russell-bugzilla]

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.