1. 03 Feb, 2014 1 commit
    • Jim Nelson's avatar
      Reduce local delays when new message arrives · 6833f1ea
      Jim Nelson authored
      In particular, bug #713493 reports this, although this patch doesn't
      appear to solve the problem entirely.  However, I have spotted
      situations in the past where the Append replay operation caused local
      operations to hang.  This is because Append was being treated as a
      local operation when, in fact, it's first call is back to the server
      to fetch UIDs of the new messages.  Hence, it should be treated as
      a remote operation so local operations can run without delay.
  2. 13 Jan, 2014 1 commit
    • Jim Nelson's avatar
      Revised handling of append/remove upcalls: Closes bgno#721326 · bd83b8bc
      Jim Nelson authored
      This approach immediately updates the remote_count when an upcall
      is received, as that math is important for determining positional
      addressing if another one immediately follows it.  However, the
      async calls only deal in the remote count *at the time the upcall
      arrived*, in effect allowing for the upcall to be serially processed
      using async blocking calls.
  3. 27 Sep, 2013 1 commit
    • Jim Nelson's avatar
      Message removed before connect reappears then disappears: Closes #7465 · 37b27e92
      Jim Nelson authored
      Problem was introduced when persistent remove markers in ImapDB.Folder
      were reintroduced.
      Also fixes issue where removing a message before connect doesn't
      have immediate response.  Conversation Monitor changed to use
      LOCAL_ONLY listing when doing a Fill Window prior to the folder
      being remote-opened.
  4. 30 Aug, 2013 1 commit
    • Jim Nelson's avatar
      Archive removes two messages, fails to show new: Closes #6085 · 9ac7349f
      Jim Nelson authored
      This is a tricky timing bug triggered by Gmail sending EXPUNGE and
      EXISTS notifications in a particular order with a slight timing delay
      between them.
      Normally Gmail will send one or more EXPUNGE notifications followed by
      EXISTS to finish up a list of removal notifications.  Even if the
      client sends an APPEND followed by STORE/EXPUNGE, the EXPUNGE
      notifications are first.
      However, if the client STORE/EXPUNGEs on one connection and a new
      message arrives from another (or via SMTP), Gmail will issue an
      EXISTS (append), wait 250 msec, then issue the EXPUNGE(s).  In
      that 250msec delay, Geary has already turned around and requested
      the new message, which no longer exists at the reported position
      because the EXPUNGEs (which have not arrived yet) have shifted it
      The solution is to pause when notifications come in so all can
      be accounted for, shifting positions as necessary.
  5. 12 Apr, 2013 1 commit
  6. 17 Jul, 2012 1 commit
    • Jim Nelson's avatar
      Reorg'd imap-impl into imap-engine · 603a3c21
      Jim Nelson authored
      The motivation is to break apart the various replay operations into
      separate source files.  The two major source files earlier
      (geary-send-replay-operations.vala and geary-receive-replay-operations.vala)
      were getting unwieldy and difficult to administer.