MBOX-Line: From dave at cridland.net  Tue Sep 12 14:34:35 2006
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] reporting/detecting expunged messages
In-Reply-To: <Pine.WNT.4.65.0609121413020.2164@Tomobiki-Cho.CAC.Washington.EDU>
References: <4505F2FE.8090807@sun.com>
	<Pine.WNT.4.65.0609111648410.5544@Tomobiki-Cho.CAC.Washington.EDU>
	<450713AB.4090601@sun.com>
	<Pine.WNT.4.65.0609121316280.2164@Tomobiki-Cho.CAC.Washington.EDU>
	<45071A57.5080406@sun.com> <20060912134217.X80085@orthanc.ca>
	<45071C8E.4010909@sun.com> <20060912134901.F80085@orthanc.ca>
	<Pine.WNT.4.65.0609121413020.2164@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <17095.1158096876.091729@peirce.dave.cridland.net>

On Tue Sep 12 22:25:59 2006, Mark Crispin wrote:
> RFC 1064 and 1176 had some text outlining the right way to go about 
> looking at the roles of client and server in IMAP.  But I took so 
> much criticism about how I did not "understand" the architecture of 
> IMAP(!) that I removed that text in RFC 1730.  [The critics in 
> question are no longer active members of the IMAP community.]
> 
> 
If it makes you feel better, I went back to those descriptions when 
designing Polymer, and found them very useful.

> In the online model, a client starts with empty state.  In the 
> disconnected model, the client has some remembered state and has to 
> synchronize that remembered state with the server's state.

FWIW, Polymer does both, in as much as it's an online client that 
manages to persist its cache between sessions. It still doesn't do 
anticipatory fetching, although I keep meaning to start putting that 
in.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

