5 ms·

Michael from Inbox here. I actually looked pretty closely at JMAP when it was announce. It's really just a JavaScript wrapper around IMAP conventions. Plus, th

by grinich 12y ago

Michael from Inbox here. I actually looked pretty closely at JMAP when it was announce. It's really just a JavaScript wrapper around IMAP conventions. Plus, there's no way to actually use it-- it's just a document spec. The thing people don't realize about IMAP being a "standard" is that there are tons of extensions, weird bugs, provider-specific edge-cases, no comprehensive tests, no reference implementation, etc. If you mean it has an RFC, then yes it's a standard. But actually working with it is still hellish. We're trying to fix email from a pragmatic, developer-focused point of view. We just want to build new apps and services without the struggle of old protocols or dealing with character encodings. The philosophical argument can come later when the dust settles.

pjc50 12y ago
This I strongly agree with: what we want now is a RESTful JSON API for email retrieval and querying. IMAP was hairy 20 years ago and is stuck with its design choices forever. But I can't see such a thing taking off unless it's Free.
- grinich 12y ago
  Free as in freedom. It's AGPL. https://www.github.com/inboxapp/inbox https://www.github.com/inboxapp/inbox
- xorcist 12y ago
  But _why_? Email does not seem RESTful to me. Not the slighest. Read an email and then flag it as unread? Save and delete instead of move? Batch operations that are not atomic? What happens when the connection breaks then? Synchronous command requests, really? IMAP solved that 20 years ago. Do we really want a glorified POP to replace it? What is the purpose?
  - pjc50 12y ago
    What do you mean by "does not seem RESTful"? It's a set of data. Writing a webmail app should be more like any other CRUD app. I don't see why that damages atomicity. Nor do I see why synchronous command requests are a problem, this works fine for AJAX. Especially if you can issue more than one at once. Store the mail in MongoDB or similar (possibly detatching the bodies of large mail for storage convenience). Stop using rfc822 as the wire format. "Move" is greatly simplified if "location" is a tag field like gmail rather than anything to do with filesystem storage. The purpose would be building web apps that manipulate email.
    - xorcist 12y ago
      The question is why you think a RESTful data model fits the problem. It is a model that fits when resources are published globally, when the CRUD methods are enough, whose purpose is to enable global caching and make hyperlinks possible. Pretty much none of this is true for email. You don't even want global caching here. You want responsivity, and a rich and extensible data model. How would you move an email? How would you control whitelisting? Spam scoring? Folder ACLs? How would you sleep until a mailbox changes? Even if you _could_ represent these things as resources, it's going to be much more hairy than IMAP with the performance of POP. The evolution of email has been completely opposite of dumbing it down. Users expect calendaring and global contact lists, and here you have the impedance mismatch _again_. Look at the mess that is CalDAV, and that's DAV which is much richer then REST. Regarding asynchronous commands, I don't know what you think it has to do with AJAX. It is the Javascript that is asynchronous in AJAX, not the HTTP requests. Web browsers typically implement it using multiple connections. This is a problem. Do you really want connection pooling (so a server can serve _fewer_ clients)? No, you want an evented protocol. Such as IMAP. And again, you probably could do it given enough work and come close to the performance of IMAP for most end users, but why would you? It doesn't really map to the REST architecture. It you would rewrite your comment but s/REST/RPC/ I would not object to it. I would just think you were from the past :).
      - pjc50 12y ago
        Are you arguing that the correct way to do webmail is to have an IMAP client in Javascript running in the browser? I think we're talking at cross-purposes here. Suppose I am writing a webmail client. Suppose I am doing this in the usual modern way of writing web applications, which is to retrieve data in JSON or XML and render it client side. I wish to retrieve some data items called "email headers" and "email bodies". I want the backend to look as much like a database as possible, relational or non-relational. I want the backend to explode mime/multipart, canonicalise things as UTF-8, fix quoted-unprintable etc. That's the application I'm aiming at. Furthermore, I'd like to standardise the transport layer enough that people can write interchangeable web frontends. As far as I know IMAP itself doesn't have any features for whitelisting and spam scoring? Nor calendaring nor global contact lists? "Move" email specifically would be implemented as updating the "location" table. An email would be allowed to be in multiple locations (qv gmail labels).

by grinich 12y ago

pjc50 12y ago

This I strongly agree with: what we want now is a RESTful JSON API for email retrieval and querying. IMAP was hairy 20 years ago and is stuck with its design choices forever. But I can't see such a thing taking off unless it's Free.

grinich 12y ago
Free as in freedom. It's AGPL. https://www.github.com/inboxapp/inbox https://www.github.com/inboxapp/inbox
xorcist 12y ago
But _why_? Email does not seem RESTful to me. Not the slighest. Read an email and then flag it as unread? Save and delete instead of move? Batch operations that are not atomic? What happens when the connection breaks then? Synchronous command requests, really? IMAP solved that 20 years ago. Do we really want a glorified POP to replace it? What is the purpose?
- pjc50 12y ago
  What do you mean by "does not seem RESTful"? It's a set of data. Writing a webmail app should be more like any other CRUD app. I don't see why that damages atomicity. Nor do I see why synchronous command requests are a problem, this works fine for AJAX. Especially if you can issue more than one at once. Store the mail in MongoDB or similar (possibly detatching the bodies of large mail for storage convenience). Stop using rfc822 as the wire format. "Move" is greatly simplified if "location" is a tag field like gmail rather than anything to do with filesystem storage. The purpose would be building web apps that manipulate email.
  - xorcist 12y ago
    The question is why you think a RESTful data model fits the problem. It is a model that fits when resources are published globally, when the CRUD methods are enough, whose purpose is to enable global caching and make hyperlinks possible. Pretty much none of this is true for email. You don't even want global caching here. You want responsivity, and a rich and extensible data model. How would you move an email? How would you control whitelisting? Spam scoring? Folder ACLs? How would you sleep until a mailbox changes? Even if you _could_ represent these things as resources, it's going to be much more hairy than IMAP with the performance of POP. The evolution of email has been completely opposite of dumbing it down. Users expect calendaring and global contact lists, and here you have the impedance mismatch _again_. Look at the mess that is CalDAV, and that's DAV which is much richer then REST. Regarding asynchronous commands, I don't know what you think it has to do with AJAX. It is the Javascript that is asynchronous in AJAX, not the HTTP requests. Web browsers typically implement it using multiple connections. This is a problem. Do you really want connection pooling (so a server can serve _fewer_ clients)? No, you want an evented protocol. Such as IMAP. And again, you probably could do it given enough work and come close to the performance of IMAP for most end users, but why would you? It doesn't really map to the REST architecture. It you would rewrite your comment but s/REST/RPC/ I would not object to it. I would just think you were from the past :).
    - pjc50 12y ago
      Are you arguing that the correct way to do webmail is to have an IMAP client in Javascript running in the browser? I think we're talking at cross-purposes here. Suppose I am writing a webmail client. Suppose I am doing this in the usual modern way of writing web applications, which is to retrieve data in JSON or XML and render it client side. I wish to retrieve some data items called "email headers" and "email bodies". I want the backend to look as much like a database as possible, relational or non-relational. I want the backend to explode mime/multipart, canonicalise things as UTF-8, fix quoted-unprintable etc. That's the application I'm aiming at. Furthermore, I'd like to standardise the transport layer enough that people can write interchangeable web frontends. As far as I know IMAP itself doesn't have any features for whitelisting and spam scoring? Nor calendaring nor global contact lists? "Move" email specifically would be implemented as updating the "location" table. An email would be allowed to be in multiple locations (qv gmail labels).