Bug 462277 (calcache)

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

NEW
Unassigned

Status

defect
P5
normal
11 years ago
2 years ago

People

(Reporter: dmose, Unassigned)

Tracking

(Depends on 8 bugs, Blocks 1 bug, {meta})

Dependency tree / graph

Details

(Reporter)

Description

11 years ago
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?
(Reporter)

Comment 2

11 years ago
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-

Comment 3

11 years ago
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]

Comment 8

9 years ago
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

Comment 9

8 years ago
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
Alias: calcache
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

Updated

5 years ago
Depends on: 1042125

Updated

5 years ago
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
You need to log in before you can comment on or make changes to this bug.