Re: [imapext] offline mode, was Re: Fwd: Request to form a new WG: JMAP

--===============5629001540636158521==
Content-Type: multipart/alternative; boundary=001a113dc4caa0d1fc0541dd2d74

--001a113dc4caa0d1fc0541dd2d74
Content-Type: text/plain; charset=UTF-8

I've said this to some client developers directly, but it's good to share
the concept more widely:

There should be no "full mirror" clients, only disconnected state clients
which make different choices of window size.  There are Gmail accounts
today which would exceed the ssd in many laptops, or the monthly bandwidth
allotment of some broadband customers.  A full sync is useful for backups,
but a regular client would be wise to make full sync a special case of
"reasonable cache space on this device/connection happens to be larger than
the user's account".

Granted, I would also argue against connected clients in general, since the
next billion users typically have poor/expensive connections, and many
users are on mobile networks where the quality can vary greatly from block
to block.  Network usage is also more likely to be a WAN these days, with
the higher latency that implies.  Also, storage size is mostly to the point
where a local cache can be fairly large compared to most content... OTOH,
shared computers may make local sync or install less desirable, but I think
most of those cases tend to web clients these days.

Brandon

On Tue, Nov 15, 2016 at 4:10 AM, Tony Finch <[email protected]> wrote:

> Is everyone here using the term "offline mode" to mean the same thing?
>
> RFC 1733 defines "offline mode" to mean POP3-style delete-from-server.
> "Disconnected mode" is the term for a client that has a local cache
> or mirror of what is on the server.
>
> Approxomately no-one wants RFC 1733 offline mode. (Bah, the number of
> times I have had to recover mail for someone who accidentally pointed an
> offline-mode client at their account.)
>
> How much do the necessary protocol features differ between a full-fat
> disconnected mode client (a mirror on the client of the entire
> account on the server) vs a poorly-connected mobile client which needs to
> sync a smaller window on the account? Concurrent access to multiple
> mailboxes? what else?
>
> Tony.
> --
> f.anthony.n.finch  <[email protected]>  http://dotat.at/  -  I xn--zr8h
> punycode
> Trafalgar: Easterly or northeasterly 5 or 6, occasionally 4 at first, but
> 6 to
> gale 8 in southeast. Moderate or rough. Fair. Good.
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext
>

--001a113dc4caa0d1fc0541dd2d74
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve said this to some client developers directly, but=
 it&#39;s good to share the concept more widely:<div><br></div><div>There s=
hould be no &quot;full mirror&quot; clients, only disconnected state client=
s which make different choices of window size.=C2=A0 There are Gmail accoun=
ts today which would exceed the ssd in many laptops, or the monthly bandwid=
th allotment of some broadband customers.=C2=A0 A full sync is useful for b=
ackups, but a regular client would be wise to make full sync a special case=
 of &quot;reasonable cache space on this device/connection happens to be la=
rger than the user&#39;s account&quot;.</div><div><br></div><div>Granted, I=
 would also argue against connected clients in general, since the next bill=
ion users typically have poor/expensive connections, and many users are on =
mobile networks where the quality can vary greatly from block to block.=C2=
=A0 Network usage is also more likely to be a WAN these days, with the high=
er latency that implies.=C2=A0 Also, storage size is mostly to the point wh=
ere a local cache can be fairly large compared to most content... OTOH, sha=
red computers may make local sync or install less desirable, but I think mo=
st of those cases tend to web clients these days.</div><div><br></div><div>=
Brandon</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Tue, Nov 15, 2016 at 4:10 AM, Tony Finch <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">Is everyone here using the term &quot;=
offline mode&quot; to mean the same thing?<br>
<br>
RFC 1733 defines &quot;offline mode&quot; to mean POP3-style delete-from-se=
rver.<br>
&quot;Disconnected mode&quot; is the term for a client that has a local cac=
he<br>
or mirror of what is on the server.<br>
<br>
Approxomately no-one wants RFC 1733 offline mode. (Bah, the number of<br>
times I have had to recover mail for someone who accidentally pointed an<br=
>
offline-mode client at their account.)<br>
<br>
How much do the necessary protocol features differ between a full-fat<br>
disconnected mode client (a mirror on the client of the entire<br>
account on the server) vs a poorly-connected mobile client which needs to<b=
r>
sync a smaller window on the account? Concurrent access to multiple<br>
mailboxes? what else?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Tony.<br>
--<br>
f.anthony.n.finch=C2=A0 &lt;<a href=3D"mailto:[email protected]">[email protected]</a=
>&gt;=C2=A0 <a href=3D"http://dotat.at/" rel=3D"noreferrer" target=3D"_blan=
k">http://dotat.at/</a>=C2=A0 -=C2=A0 I xn--zr8h punycode<br>
Trafalgar: Easterly or northeasterly 5 or 6, occasionally 4 at first, but 6=
 to<br>
gale 8 in southeast. Moderate or rough. Fair. Good.<br>
<br>
______________________________<wbr>_________________<br>
imapext mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/imapext" rel=3D"noreferrer=
" target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/imapext</a><=
br>
</font></span></blockquote></div><br></div>

--001a113dc4caa0d1fc0541dd2d74--


--===============5629001540636158521==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp

--===============5629001540636158521==--