Last Comment Bug 361520 - Handle autorefresh and/or refreshing and reload of CalDAV calendars
: Handle autorefresh and/or refreshing and reload of CalDAV calendars
Status: RESOLVED DUPLICATE of bug 389397
:
Product: Calendar
Classification: Client Software
Component: Provider: CalDAV (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-22 07:00 PST by lionel valero
Modified: 2007-09-08 05:44 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description lionel valero 2006-11-22 07:00:24 PST
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 2006-11-22 07:18:49 PST
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 2006-11-23 08:15:15 PST
Actually in the nightly build version of Sb the feature is not available for a caldav calendar.
Comment 3 Matthew (lilmatt) Willis 2006-11-23 10:20:06 PST
Yes, "Reload" is disabled for CalDAV calendars in all Sunbird and Lightning builds.
Comment 4 Damian Szczepanik 2007-01-20 13:47:23 PST
can we close this issue? not sure if this is still valid
Comment 5 Bruno Browning 2007-01-21 08:34:10 PST
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 2007-01-21 12:50:12 PST
jminta and/or dmose:
Regarding Bruno's comment #4, should we allow auto-reload for CalDAV calendars?
Comment 7 cmtalbert 2007-03-21 12:20:55 PDT
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 2007-05-15 06:31:11 PDT
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 2007-07-23 07:05:49 PDT
(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] 2007-07-26 12:01:43 PDT
IMO duplicate to bug 389397.

*** This bug has been marked as a duplicate of bug 389397 ***
Comment 11 russell-bugzilla 2007-08-03 08:22:33 PDT
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 2007-08-03 08:43:47 PDT
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 2007-08-03 12:07:23 PDT
(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 2007-08-09 04:55:24 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.