Re: [Imap-protocol] If Crispin were creating IMAP today how would it be different?

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 <[email protected] (mailto:[email protected])> 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
> > [email protected] (mailto:[email protected])
> > _______________________________________________
> > Imap-protocol mailing list
> > [email protected] (mailto:[email protected])
> > http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
> >  
>  
> _______________________________________________
> Imap-protocol mailing list
> [email protected] (mailto:[email protected])
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>  
>

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol