Wed 2008/Mar/19

• Philip, you are looking at this from the viewpoint of email. Email, addressbooks, and calendars are pretty different beasts.

  Email has very particular access patterns, which are totally different from calendars and addressbooks.

  With email, the prevailing model is that you display a usually huge linear list of messages, and even the summarized information can be pretty big. Searching is Nontrivial(tm).

  In calendars, you almost always look at a subset of "events which occur in a certain range of dates", by virtue of the calendar's view (monthly/weekly/daily). Practically the only exception to this is when you want to do "show me events which contain $substring"; that's when you actually want to show a linear list of all the events that match.

  Evolution still doesn't get this right, by the way. If I'm thinking, "when did I meet with Joe?", I type "Joe" in the search box — but Evolution keeps showing the current monthly/weekly/daily view, and I have to manually fiddle with the date ranges to actually find which days contain the event I'm looking for. Substring searches should switch to the "list view" mode.

  Addressbooks are funny, because the access patterns for "my addressbook" and "my company's directory" are very different. Your addressbook contains at most a few hundred entries, and you may be able to deal with it comfortably by scrolling through a linear list, which is sorted by last name. You turn on searching when you don't remember a person's last name, so you type their first name in the search box.

  In contrast, your company's directory is potentially huge and you never want to show it as a linear list. You actually want to type a person's name in a search box, and then pick a match from a small list. (Something must be wrong somewhere, as people keep mailing me when they mean my colleague with the beautiful name).

  What does this have to do with evolution-data-server? E-d-s was always meant to be a local daemon to store your calendar and addressbook. It's the local Model in a Model/View split for all the processes which want to access your calendar/addressbook data. It was also meant to act as a local cache for remote calendars, which could be slow/huge/etc — that is, for stuff which is far away or not in the same scale as your own little appointments.

  I really don't know how much of that data gets duplicated in the daemon's clients, but if it is a lot, then the clients are doing something wrong. For example, a calendar event (VEVENT in iCalendar parlance) contains a lot of administrative crap: a UUID, a sequence number, a stringified timezone identifier, blah blah blah, in addition to the actual human-readable stuff that I can see in my calendar (summary, start/end times, alarms). Here's a complete VEVENT:

  BEGIN:VEVENT
  UID:20070925T174038Z-22251-100-1-25@cacharro
  DTSTAMP:20070925T174038Z
  DTSTART:20070926T160000Z
  DTEND:20070926T170000Z
  SEQUENCE:2
  SUMMARY:openSUSE project meeting #opensuse-project
  CLASS:PUBLIC
  TRANSP:OPAQUE
  CREATED:20070925T174109
  LAST-MODIFIED:20070925T174109
  BEGIN:VALARM
  X-EVOLUTION-ALARM-UID:20070925T174109Z-5309-100-1-13@cacharro
  DESCRIPTION:openSUSE project meeting #opensuse-project
  ACTION:DISPLAY
  TRIGGER;VALUE=DURATION;RELATED=START:-PT15M
  END:VALARM
  END:VEVENT
  

  That's 484 bytes of data, which is mostly fluff. These structures tend to explode in size when you parse them, but a neurotic calendar could keep the nice-and-small VEVENT string instead of a parsed structure, and re-parse it and re-generate it every time the event changes.

  And again: my local calendar, which goes back to 2001, only contains about 500 events, and is 670 KB in size. The craziest calendar I've seen is Michael's, which has a couple thousand events, but that's not even an order of magnitude larger than mine.

  Summary: there's no reason for e-d-s or calendar clients to have huge memory requirements; they are just doing something silly. You can keep a whole calendar, in memory, in less space than a fat JPEG from your digicam.

Syndicated 2008-03-19 13:30:00 from Federico Mena-Quintero - Activity Log