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)
Calendar
Internal Components
Tracking
(Not tracked)
NEW
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?
Comment 1•16 years ago
|
||
Reporter | ||
Comment 2•16 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•16 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
Comment 4•16 years ago
|
||
(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.
Comment 5•16 years ago
|
||
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.
Comment 6•16 years ago
|
||
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.
Updated•15 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 7•15 years ago
|
||
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.
Updated•14 years ago
|
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 ;-)
Updated•14 years ago
|
Comment 9•13 years ago
|
||
Is this a blocker? It seems like it might be a destabilizing change so close to shipping.
Comment 10•13 years ago
|
||
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.
Comment 11•13 years ago
|
||
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)
Comment 12•13 years ago
|
||
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?
Comment 13•13 years ago
|
||
The id was changed for comm-central on push, I think we are fine :)
Updated•12 years ago
|
Summary: Turn on experimental cache by default → Turn on offline cache by default for new calendars
Whiteboard: [not needed beta][no l10n impact]
Comment 14•11 years ago
|
||
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
Updated•11 years ago
|
Alias: calcache
Comment 15•11 years ago
|
||
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
Comment 16•8 years ago
|
||
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
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•