1. 24 Apr, 2012 1 commit
  2. 09 Jan, 2012 1 commit
  3. 17 Nov, 2011 1 commit
    • Jim Nelson's avatar
      Fetches only a small portion of the message for previews: Closes #4254, Closes #3799 · 18716ae6
      Jim Nelson authored
      Before we were fetching the entire message body (including attachments) to get the
      preview text.  This patch now offers the ability to fetch a small (128 byte) preview
      of the email.
      
      Also, since this ticket is about speeding up performance, I've introduced NonblockingBatch,
      which allows for multiple async operations to be executed in parallel easily.  I've added
      its use in a few places to speed up operations, including one that was causing the lag
      in #3799, which is why this commit closes that ticket.
      18716ae6
  4. 18 Oct, 2011 1 commit
    • Jim Nelson's avatar
      FETCH BODY[section]<partial> support. · db62ed5d
      Jim Nelson authored
      This adds support for retrieving partial header and body blocks straight from the email, and
      therefore support to pull the References header from a message (which, for some reason, IMAP
      doesn't support or include in the FETCH ENVELOPE command).  This is necessary for email conversations (#3808).
      
      This required a change to the database schema, meaning old databases will need to be blown
      away before starting.
      db62ed5d
  5. 15 Jul, 2011 2 commits
    • Jim Nelson's avatar
      Further work on detecting message removal when folder first selected: #3805 · 0533bc97
      Jim Nelson authored
      Needed to rethink storage strategies as I researched this and realized that a true scarce database -- where the database is sparsely populated both in columns and rows -- is not feasible due to IMAP's UID rules.  The strategy now means that the database rows are contiguous from the highest (newest) message to the oldest *requested by the user*.  This is a better situation than having to download the UID for the entire folder.
      0533bc97
    • Jim Nelson's avatar
      Implemented IMAP-specific folder and message properties tables: #3805 · 6b8951bf
      Jim Nelson authored
      This commit adds support for IMAP-specific properties, of which UIDValidity is crucial toward completing #3805.  The additional code is to integrate these tables into the SQLite Geary backend and to make sure this information is requested from the IMAP server.
      
      NOTE: This commit changes the database schema.  Old databases will need to be blown away before running.
      6b8951bf
  6. 24 Jun, 2011 1 commit
    • Jim Nelson's avatar
      Persist messages locally: #3742 · d179cb9b
      Jim Nelson authored
      This completes the heavy lifting of persisting messages locally.  The strategy is that the local database may be sparsely populated, both in the availability of messages in a folder and the fields of a message that is partially stored.  As data is pulled from the remote server it's always stored in the database.  Future requests will always go to the database first, preventing unnecessary network traffic.
      
      Also, this patch will detect when a message is stored in multiple folders on the server.  The database uses soft links from the folder to the message, so the message is stored only once in the database.  This technique relies heavily on the availability and validity of the Message-ID header, but we expect this to be reliable the vast majority of the time.
      d179cb9b
  7. 22 Jun, 2011 1 commit
  8. 16 Jun, 2011 1 commit
    • Jim Nelson's avatar
      Addition of MessageTable and MessageLocationTable toward fixing #3742. · 9221937e
      Jim Nelson authored
      Much of the API between the local and net stores had to be reworked for consistency as well as planning ahead for how messages will be retrieved and stored efficiently.  This work also attempts to keep in mind that other mail sources (POP, etc.) may be required in the future, and hopefully can be added without major rework.
      9221937e
  9. 11 Jun, 2011 1 commit
    • Jim Nelson's avatar
      First stab at implementing persistent storage of IMAP data: #3695. · 4b8ac568
      Jim Nelson authored
      This large diff represents a growth of the architecture to persist IMAP data as its downloaded.  When listing folders, a local database is consulted first to immediately feed to the caller.  In the background, network calls fetch the "real" list.  The two are collated for differences which are reported to the caller via signals, who are then responsible for updating the user interface appropriately.  No other synchronization work is represented in this diff.
      
      Note that this breaks functionality: when a folder is selected, no messages appear in the message list.  Fixing this requires more work, and this patch was already large enough.  It's ticketed here: #3741
      4b8ac568