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>
