Summit Part 3: Lightning

Bron Gondwana brong at fastmail.fm
Fri Oct 24 00:48:39 UTC 2014


On Thu, Oct 23, 2014, at 05:42 PM, Archaeopteryx wrote:
> -------- Original-Nachricht --------
> Betreff: Summit Part 3: Lightning
> Von: Kent James <kent at caspia.com>
> Datum: 2014-10-23 22:56
> > 2) There has been a sense (rumor?) that Lightning performance was not
> > ready to be included with the core product. Nobody at the Summit was
> > able to confirm this as an issue, so there was no sense that this should
> > be a blocker.
> 
> For people will large calendars, this will impact startup time even if 
> the calendar is not open. With a fast machine and an SSD, having a 
> calendar with 700 events doubles startup time from <2 seconds to 4 
> seconds. For more events and weaker hardware, expect higher startup times.

This sounds like a kind of excellent case for dumping the binary representation to disk and slurping it back in.  Most of the startup cost of calendar stuff appears to be parsing, particularly recurrence rules (in my experience at least).  We have the same issue at FastMail, and if it becomes bad enough, we plan to just dump the JSON representation into a local cache and invalidate it on sync-token change.

> Shipping Lightning with Thunderbird also opens the opportunity to make 
> profiles with Lightning cross-OS compatible if Lightning lives outside 
> the user profile. The downside is that updating it independent from 
> Thunderbird needs more work (and also likely removing Lightning from the 
> user profile).
> 
> Integrating Lightning makes it also possible to use Thunderbird as a 
> standalone calendar client, so the "Do you want a new mail address or 
> add an existing one?" dialog should become permanently dismissable in 
> that case.

It's tricky to do calendaring without at least some email support - particularly if the calendar server doesn't support server-side scheduling.

Bron.

-- 
  Bron Gondwana
  brong at fastmail.fm



More information about the tb-planning mailing list