91 lines
3.7 KiB
Plaintext
91 lines
3.7 KiB
Plaintext
MBOX-Line: From dinh.viet.hoa at gmail.com Mon Mar 9 12:05:30 2015
|
|
To: imap-protocol@u.washington.edu
|
|
From: "Hoa V. DINH" <dinh.viet.hoa@gmail.com>
|
|
Date: Fri Jun 8 12:34:54 2018
|
|
Subject: [Imap-protocol] If Crispin were creating IMAP today how would
|
|
it be different?
|
|
In-Reply-To: <6506.1425915329@parc.com>
|
|
References: <54FAEB94.4070508@lavabitllc.com> <54FBF289.3010202@psaux.com>
|
|
<7164.1425831184@parc.com>
|
|
<1425907661.1215497.237833469.1EDA571D@webmail.messagingengine.com>
|
|
<6506.1425915329@parc.com>
|
|
Message-ID: <B03452330F6149E180E449A493F28C2B@gmail.com>
|
|
|
|
By using a generic DB protocol to sync emails, it sounds like it would be easy to break your email database consistency.
|
|
It would also add a big constraints with the choice of implementation of the storage of the emails on server side and client side.
|
|
|
|
There was also a mention of using a binary protocol in this thread.
|
|
I think using human readable text protocol is still a very good idea since it makes it easier to debug just by logging input/output of the protocol.
|
|
I?ve used a lot this way of debugging things: for IMAP, SMTP and (unrelated but for) HTTP requests.
|
|
|
|
--
|
|
Hoa V. DINH
|
|
|
|
|
|
On Monday, March 9, 2015 at 8:35 AM, Bill Janssen wrote:
|
|
|
|
> Bron Gondwana <brong@fastmail.fm (mailto:brong@fastmail.fm)> wrote:
|
|
>
|
|
> > > And let the DB guys solve the intermittent connection problems :-).
|
|
> > > Oracle, for instance, has a "Mobile Server" product that synchonizes a
|
|
> > > local cache on a mobile device with a remote Oracle DB, including SSL
|
|
> > > encryption on the sync connection, and data compression.
|
|
> > >
|
|
> >
|
|
> >
|
|
> > The problem is, DB protocols are pretty chatty. And you need to solve
|
|
> > authencation too.
|
|
> >
|
|
>
|
|
>
|
|
> I'm guessing that's why Oracle has a sync protocol instead of a remote
|
|
> DB protocol. The mobile client works against an on-phone copy of the
|
|
> DB, using a variant of Oracle's full SQL -- the documentation says it is
|
|
> SQLite compatible -- and then there's a minimal sync protocol which
|
|
> keeps that in step with the full DB back on the server. Interesting
|
|
> question as to whether the on-phone copy is a subset or not.
|
|
>
|
|
> > Seriously, I think we've pretty much done what you're suggesting in
|
|
> > JMAP, but we've solved the latency problems that chatty protocols have
|
|
> > when you don't have a nice short piece of solid copper between you and
|
|
> > the server as well.
|
|
> >
|
|
>
|
|
>
|
|
> Sure, JMAP's great, but it's very email-specific. Seems to me this is a
|
|
> problem which lots of other domains have as well. So: take JMAP, skip
|
|
> the enumeration of email object types, generalize the getFooUpdates to
|
|
> get/putTableUpdates, add some ability to specify per-table
|
|
> parameterization which says things like how much of the remote table you
|
|
> need locally, how frequently it needs to be updated, how precious
|
|
> on-device changes are, etc., and you've got a general protocol.
|
|
>
|
|
> That way, when you want to add a new object type, say Conference Rooms,
|
|
> you don't need to change the protocol.
|
|
>
|
|
> Bill
|
|
>
|
|
> >
|
|
> > Bron.
|
|
> >
|
|
> > --
|
|
> > Bron Gondwana
|
|
> > brong@fastmail.fm (mailto:brong@fastmail.fm)
|
|
> > _______________________________________________
|
|
> > Imap-protocol mailing list
|
|
> > Imap-protocol@u.washington.edu (mailto:Imap-protocol@u.washington.edu)
|
|
> > http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
> >
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu (mailto:Imap-protocol@u.washington.edu)
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
>
|
|
|
|
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150309/9cc04d4a/attachment.html>
|