From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.142.178.13 with SMTP id a13cs70611wff; Mon, 23 May 2011 15:52:52 -0700 (PDT) Received: by 10.52.73.34 with SMTP id i2mr4374814vdv.166.1306191170695; Mon, 23 May 2011 15:52:50 -0700 (PDT) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id v16si5015333vbp.44.2011.05.23.15.52.50; Mon, 23 May 2011 15:52:50 -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 34FE618583AC for ; Mon, 23 May 2011 18:52:50 -0400 (EDT) X-Greylist: delayed 308 seconds by postgrey-1.31 at rubyforge.org; Mon, 23 May 2011 18:29:25 EDT Received: from mail-px0-f176.google.com (mail-px0-f176.google.com [209.85.212.176]) by rubyforge.org (Postfix) with ESMTP id EE0BD18583A8 for ; Mon, 23 May 2011 18:29:25 -0400 (EDT) Received: by pxi11 with SMTP id 11so4500272pxi.35 for ; Mon, 23 May 2011 15:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=ODY4Tm3UBm70F3+xyVi3q65hF6/9DpG5UanblYmR0eo=; b=sfqyY1SMYVtPZkVFjDn6o1GMB8x3LMxu4yK8XRyM7MMkbntFV8XWJm2G7Qz1FARUUN iGL2e67xP8rB8gkobd0jRTbsG7Dp7+QQMPbhCVNWByWUqnKbaj+SBoez16g4nhyAhYkh 3/7DgFV6UdgQtUCk4Xnf7ExyhyR2ZR3tc4CLA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=VhpFU1pZs4LZs0DKfcyo7aXpq5q/L41AtAhq86fWDnfiP3gEwxbuMSUfGmb2YMoR31 P1jrMus13t9KuuPI64ELcoaMIVNhSRtXFrnGGjVHCy3psZE8E8hTrNkh3G5RNpen3Q3W e0KDrMRW6au2tuAAV7moQukjFv0E9uvjnf73Y= Received: by 10.68.40.98 with SMTP id w2mr2222066pbk.144.1306189453333; Mon, 23 May 2011 15:24:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.63.65 with HTTP; Mon, 23 May 2011 15:23:58 -0700 (PDT) In-Reply-To: References: From: Vivien Didelot Date: Mon, 23 May 2011 18:23:58 -0400 Message-ID: To: Sup developer discussion Subject: Re: [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: multipart/mixed; boundary="===============0081453209==" Sender: sup-devel-bounces@rubyforge.org Errors-To: sup-devel-bounces@rubyforge.org --===============0081453209== Content-Type: multipart/alternative; boundary=bcaec53af0e060152804a3f8ee82 --bcaec53af0e060152804a3f8ee82 Content-Type: text/plain; charset=ISO-8859-1 Hi Horacio, FWIW, you may use -- or even just take a look at -- the 'gmail' gem. It works pretty well for back syncing and is built on RFCs too (if I'm not mistaken). For maildir backsyncing, the 'maildir' gem also do the job, both are using the great 'mail' gem (which I hope, Heliotrope & co will use soon). Vivien. On Mon, May 23, 2011 at 10:42 AM, Horacio Sanson wrote: > 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