Re: twitter

[Michael Grinich]

I'm CCing this to our list of developers, because I think it's an interesting discussion to pull other folks into if they have comments. Inbox is more and more a community effort too.

The Inbox API isn't designed to be a "replacement" for IMAP and current mail standards, in the sense that it actually removes many features of IMAP. These are specific features that we feel offer marginal flexibility at the cost of incredible complexity. MIME structures is an example of this. Another is the plethora of ways to declare character encodings via RFC-2822 style messages. With the Inbox API, there is only a single `body` object and it's always unicode.

I also agree that HTTP/JSON isn't the most elegant or glorious protocol. But the reality is that today's developers and browsers+libraries know how to work with it, so if our goal is to help developers, then it's the right thing to use. Similarly, the removal of session state (e.g. `SELECT`ing folders) from the protocol, and adding predictable URIs also matches the way developers think about modern APIs.

We're also really excited about the Delta Sync Endpoint, which converts a users' mailbox from a standard file-based representation into a transactional log of events. You need something like this to have multi-client sync, and it's opening up new ways of building super lightweight apps that can still connect and process mail data. With this API plus our websockets-based Ping endpoint, we could essentially build a new streaming sync service. But that's a ways off.

In actuality, much of the Inbox API's surface-level design can easily be swapped out for another protocol or datatype. See the kellogs.py module for details on our current serialization formats. Right now more focused on providing a great product that has roots in a large open-source codebase, and would rather leave the protocol arguments to the IETF and other folks. If someday people want to migrate towars IMAPv5, JMAP, or "SMPLY" then it would be easy to add on top of Inbox. 

But there's still a lot of catching up to do in the world of email before we invent something brand new. Developers need working code, not more RFCs to read.

--Michael

On Fri, Aug 15, 2014 at 1:29 AM, Andrei Neculau <andrei....@gmail.com> wrote:

The good thing with mails is that they never grow old. Sorry about the late after-summer-vacation reply

SMPLY was *simply* an acronym of an imaginary protocol to supersede IMAP, on the same level with SPDY in relation to HTTP.

But when I say supersede, I mean it exactly in HTTPbis&HTTP2 terms - tweaking the essentials in order to simplify and improve. Or as the saying goes: simplify to amplify.

Let it be clear that using developer's cognitive skills as a reference is a dead end. As a literature analogy, your (and there are so many others that **add** layers in order to **simplify**) effort equates to "lets figure out how to write poetry with http://en.wikipedia.org/wiki/Most_common_words_in_English because thats something that every English speaker understands"

While I don't have adequate IMAP knowledge, I take the state of IMAP usage and implementation quality to be similar to the state of HTTP (an area where I know more than I want to know http://vimeo.com/78030876 ).

Parsers and generators are not up to par with the standard, implementation of clients and servers are either too minimalistic, either holistic, with any correlation to software quality, no tagging of feature importance in a plethora of features defined by the standard.

One option is to use a hammer with everything, no matter if it's a nail or not. "REST" (CRUD HTTP) + JSON all the way. That doesn't say much at all though, because the semantics are left for later or never. It would be good at least to hear that the Inbox REST API covers ~5% of the whole IMAP functionality, and say ~75% of the "most used" functionality.

But the option I was poking in the tweets was to actually 1) simplify implementations 2) decide what is the core IMAP functionality 3) simplify and improve the standard by adding a **compatible** protocol layer. e.g. talk to a SMPLY server with IMAP commands only or for basic functionality use SMPLY commands that might be 99% REST/HTTP-ish and JSON and have a 1% thin layer that is actually a HTTP <-> SMPLY translator.

Furthermore, the IETF poke was not to praise the IETF work and the outdated ways of working, but to praise the strive for a standard and the standardising environment as a whole. Cognitive skills, business goals, etc will always change (often without any good reason) only to find ourselves investing in perpetual shortly-lived incompatible implementations: see the syntax of programming languages, see the social APIs, see the text-document formats, etc.

Cheers,

Andrei

On Thu, Jul 10, 2014 at 2:27 AM, Michael Grinich <m...@inboxapp.com> wrote:

:)

Thanks for the beginnings of a good discussion on twitter!

I'm curious about your more specific feedback regarding our API. What did you mean by SMPLY?

Our approach is that IMAP is hard to work with, and today's developers understand REST and JSON. So we should be a layer between IMAP and REST+JSON.

Thanks in advance for your thoughts.

Michael

On Mon, Jul 7, 2014 at 3:32 PM, Andrei Neculau <andrei....@gmail.com> wrote:

ping

or closer to the context: OK andreineculau ready

--

andreineculau.com

--

andreineculau.com