568461 - CalDAV: Refresh calendar after any modification

Status: NEW

(Calendar :: Provider: CalDAV, enhancement)

Description

[Dimas]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.19) Gecko/2010040116 Ubuntu/9.04 (jaunty) Firefox/3.0.19
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.0.19) Gecko/2010040116 Ubuntu/9.04 (jaunty) Firefox/3.0.19 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.1.11pre) Gecko/20100519 Lightning/1.0b2pre Shredder/3.0.6pre

I think it would be a good idea to refresh the calendar after any modification (creation, edition or deletion).

Reproducible: Always

Comment 1

[Dimas]

Attachment: Patch for Bug 568461

This enhancement can be implemented with this patch.

Comment 2

[Philipp Kewisch [:Fallen][📱📆]]

So what happens on a batch operation, where many events are changed at once? Does this patch make sure there is only one refresh afterwards?

Given our current performance situation, I'm not sure this is the best idea. If the calendar has many entries and it takes a while to reload things, then refreshing on add/modify/delete will make things seem even slower for the user.

Comment 3

[Simon Vaillancourt]

Comment on attachment 447753 [details] [diff] [review]
Patch for Bug 568461

I like general idea of the fix but we should make sure Philipp concerns are addressed, ie: what happens when you "Dismiss All" a bunch of alarms? Or when you import a lot of meetings?

Also this would be optimal only for servers supporting webdav sync.

Comment 4

[Stefan Fleiter (:sfleiter)]

What's the motivation for refreshing here?

Is it https://tools.ietf.org/html/rfc4791#section-5.3.4:

   In the case where the data stored by a server as a result of a PUT
   request is not equivalent by octet equality to the submitted calendar
   object resource, the behavior of the ETag response header is not
   specified here, with the exception that a strong entity tag MUST NOT
   be returned in the response.  As a result, clients may need to
   retrieve the modified calendar object resource (and ETag) as a basis
   for further changes, rather than use the calendar object resource it
   had sent with the PUT request.

?

Comment 5

[holocronweaver]

Perhaps this could be a temporary workaround to bug 924604 where the cache is not reliable?

Comment 6

[Eric L.]

I have the issue that my calendar (CalDav against Google Calendar) doesn't show changes until I've hidden then shown the calendar. Changes can be drag&drop an event, or the shade of color change when accepting/rejecting an event. Could this change be a solution for my issue, or shall I create a new ticket?