Disable wcap caching until dependant bugs are fixed

VERIFIED FIXED in 0.8

Status

defect
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: Fallen, Assigned: Fallen)

Tracking

(Blocks 1 bug)

unspecified
Dependency tree / graph
Bug Flags:
blocking-calendar0.8 +

Details

Attachments

(1 attachment)

This pref was taken out since we wanted offline support to be visible by default and it was enough to have the pref in the properties dialog, but we have found out that its probably not a bad idea to keep offline invisible by default and tell users how to enable it. It is way to experimental to be default-on.
Flags: blocking-calendar0.8+
I am not sure really if we want this, because it keeps off users from testing the feature. I agree that it's doubtful to switch it on since mostly only users with *big* calendars are waiting for this feature (in hope that it will speed up their calendars)... and unless the (local) cache calendar is slower than the networked (uncached) one, this is absurd.

Disregarding the slow initial sync, the feature works quite well for me on small to medium sized calendars. WCAP in particular has another problem, i.e. bug 412606; that bug disables WCAP to distinguish invitations from owned items. Assuming it won't be fixed for the release, (at least) WCAP should be switched off.
Checking in WCAP fix until the bugs specified in the "blocks" field are fixed.

We decided to leave offline support initially on.

Checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Blocks: 412606, 412914
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Summary: The return of calendar.cache.enabled... → Disable wcap caching until dependant bugs are fixed
Target Milestone: --- → 0.8

Comment 3

12 years ago
Checked in nightly build 2008011718 -> task is fixed and verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.