Open Bug 462277 (calcache) Opened 16 years ago Updated 2 years ago

[meta][GSoC 2014] Turn on offline cache by default for new calendars

Categories

(Calendar :: Internal Components, defect, P5)

Tracking

(Not tracked)

People

(Reporter: dmosedale, Unassigned)

References

(Depends on 6 open bugs, Blocks 1 open bug)

Details

(Keywords: meta, perf)

They are currently turned off because of various issues. I'd be interested in knowing how much work it's likely to be to get them in shippable shape.
Flags: tb-integration?
After some discussion, we've marked this a tb-integration-. It's conceivable that we'll decide in the future that cached calendars is the best way to address some performance issue that we need for tb-integration, but just the ability to work offline we probably wouldn't block on.
Flags: tb-integration? → tb-integration-
There might also be a problem with the experimental cache and GData that prevents users from dismissing reminders. There is a long thread in the Mozillazine forums, here is page 4: http://forums.mozillazine.org/viewtopic.php?p=4791935#p4791935
(In reply to comment #3) > There might also be a problem with the experimental cache and GData that > prevents users from dismissing reminders. There is a long thread in the > Mozillazine forums, here is page 4: > http://forums.mozillazine.org/viewtopic.php?p=4791935#p4791935 I assume this is bug 411558. Note that caching gdata calendars is something I'd really like to see, since right now *a lot* of requests are done, which is far from optimal.
oops, had the wrong issue in mind, but something similar. Aside from that, we need a faster storage calendar, since sometimes uncached behavior is much faster than the cached version. I have some code lying around that quickens the storage provider, but its basically a rewrite and requires some advanced migration.
Gloda was designed as a fast index to other sources (in its original case, mork dbs). I wonder if using Gloda as a cache for calendars makes sense.
OS: Mac OS X → All
Hardware: x86 → All
It would be nice if we could get the cache into a mature state so its possible to do this by default for all calendars. Once this step is through, we can improve our search capabilities by using the gloda indexer also for calendar items.
Flags: wanted-calendar1.0+
Summary: turn on cached calendars → Turn on experimental cache by default
Flags: wanted-calendar1.0+ → blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
Can we please replace "depends on bug:528811" by "depends on bug:477287" ? Because 528811 has been marked as dup of 477287. Thanks ;-)
Depends on: 477287
No longer depends on: 528811
Is this a blocker? It seems like it might be a destabilizing change so close to shipping.
The idea behind this being a blocker was that if everything works as expected, it could greatly improve performance and user experience. Network load will be greatly decreased, the user will not have to enable the cache for offline support to work and especially for caldav the performance increase for accessing events is substantial. I agree it might be too risky though, there is no way this should happen without greater test coverage and its probably too much to ask for just a few months.
For an 1.0 release we should avoid naming things experimental. On the other hand, our strings are frozen so we don't want to go out changing things. To get the best of both worlds, I have discussed with Mark that we will change the string content in en-US only in beta and aurora and notify localizers that they should optionally change their string too. I'll send out email to dev.l10n soon. Note the following checkin doesn't actually make the cache default, but marks it no longer experimental. I think that fits in well with the scope of this bug. comm-beta changeset 09bcb1cd1240 comm-aurora changeset 80e15b7801d2 comm-central changeset 39274b8328ee (with id change)
Do we have a follow-up bug, that will change the string ID, so that we can catch locales, that won't make this optional change after 1.0 is released?
The id was changed for comm-central on push, I think we are fine :)
Blocks: 768207
Depends on: 742528
Summary: Turn on experimental cache by default → Turn on offline cache by default for new calendars
Whiteboard: [not needed beta][no l10n impact]
Depends on: 790590
Depends on: 788004
I'm turning this into a meta bug since it nicely gathers some of the issues we are having with the cache. I think moving towards cache-only mode should be a higher priority on our roadmap.
Component: Calendar Views → Internal Components
Flags: tb-integration-
Flags: blocking-calendar1.0+
Keywords: meta
Priority: -- → P2
Summary: Turn on offline cache by default for new calendars → [meta] Turn on offline cache by default for new calendars
I'm turning this into the tracking bug for Reid's 2014 GSoC project. This bug might contain a few more dependencies than required for completing the project, but I think it gives a good overview.
Assignee: nobody → anderson
Status: NEW → ASSIGNED
Summary: [meta] Turn on offline cache by default for new calendars → [meta][GSoC 2014] Turn on offline cache by default for new calendars
Depends on: 1042125
Depends on: 1055111
The GSoC is long over, unfortunately we didn't quite finish this project, even though a lot of good progress was made. Reid, if you are still around and want to get back to contributing (even if not this bug), I'd be happy to hear from you!
Assignee: anderson → nobody
Status: ASSIGNED → NEW
Priority: P2 → P5
Keywords: perf
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.