From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.142.178.13 with SMTP id a13cs57047wff; Mon, 23 May 2011 07:42:33 -0700 (PDT) Received: by 10.52.18.72 with SMTP id u8mr2149725vdd.290.1306161752542; Mon, 23 May 2011 07:42:32 -0700 (PDT) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id u16si2495703vcf.42.2011.05.23.07.42.31; Mon, 23 May 2011 07:42:32 -0700 (PDT) Received-SPF: pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-devel-bounces@rubyforge.org; dkim=neutral (body hash did not verify) header.i=@gmail.com Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id D48203C8033 for ; Mon, 23 May 2011 10:42:31 -0400 (EDT) Received: from mail-vw0-f50.google.com (mail-vw0-f50.google.com [209.85.212.50]) by rubyforge.org (Postfix) with ESMTP id 71B29185837F for ; Mon, 23 May 2011 10:42:16 -0400 (EDT) Received: by vws14 with SMTP id 14so5497032vws.23 for ; Mon, 23 May 2011 07:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=JOd+EZIGxFSABkypg0cSjKw2luotkBfU++00XKKzPJo=; b=k3ctzlo3zbtFTzjf7YpyACQvcmuDUsnotMuDd73InnZqiV2uERrpGEoD3rtCChE5qU oy4p8xpAEWEYZ4gvWQZJn3oHpnKaP2NyO3oTyMVGxZmDRMJyQi8/zD+ozDnN5UunzP19 cGCOnKxLyBFBORIWgc9ONwMIXiuXJSV4HyUYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=L42i/Tlek2+q4j5I/Xr8yh6i8yPssVFCQZMJ7RMIbJ9tQ3XOJsDDtDsQNJVXhzpUBz L5x0/ZYQf0j8CBhAobYKu85qhweNZn6sL+ils5NK79RrI/ypWUD1e1a9vL1IXlFieXVf hDoFpcDn3S9nleTaDPcKXR68QhB19gQw7Fzwc= MIME-Version: 1.0 Received: by 10.52.69.205 with SMTP id g13mr764981vdu.241.1306161736070; Mon, 23 May 2011 07:42:16 -0700 (PDT) Received: by 10.52.112.100 with HTTP; Mon, 23 May 2011 07:42:16 -0700 (PDT) Date: Mon, 23 May 2011 23:42:16 +0900 Message-ID: From: Horacio Sanson To: Sup developer discussion Subject: [sup-devel] Heliotrope limitations for backward synchronization, , , X-BeenThere: sup-devel@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sup developer discussion List-Id: Sup developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sup-devel-bounces@rubyforge.org Errors-To: sup-devel-bounces@rubyforge.org Now that I have GMail to Heliotrope initial synchronization (first time) and incremental (new messages) synchronization working in my script I started working on Heliotrope to GMail synchronization. Unfortunately I found some difficulties to achieve this. I am following rfc4549.txt and the client-to-server synchronization says verbatim: c) "Client-to-server synchronization": for each IMAP "action" that was pending on the client, do the following: 1) If the action implies opening a new mailbox (any operation that operates on messages), open the mailbox. Check its UID validity value (see Section 4.1 for more details) returned in the UIDVALIDITY response code. If the UIDVALIDITY value returned by the server differs, the client MUST empty the local cache of the mailbox and remove any pending "actions" that refer to UIDs in that mailbox (and consider them failed). Note that this doesn't affect actions performed on client-generated fake UIDs (see Section 5). 2) Perform the action. If the action is to delete a mailbox (DELETE), make sure that the mailbox is closed first (see also Section 3.4.12 of [RFC2683]). Seems simple to do but Heliotrope currently does not store/provide enough information to implement this like: 1) Account and Mailbox information of messages. 2) Heliotrope msg_id to GMail UID map. 3) Per mailbox action FIFO queues. Each action performed via Heliotrope (add label, remove label, state change, delete) should be stored in some kind of FIFO associated to the an account/mailbox pair. For example adding a label to a message in my personal account's inbox would add an action like: label_add