jtmoulia

In what ways are the current batch of email clients primitive, and how do you think they can move forward?

IMAP is difficult to develop on.

1. IMAP's base spec (RFC 3501 [1]) offloads implementation on the client rather than the server. For example, the client must be able to parse the IMAP protocol, it must have be able to create threads by searching through emails, it needs to implement the logic for syncing, ... etc.

2. There are many IMAP extensions to patch the issues of the original spec [2], but implementation of these extensions across email providers is fragmented, and implementing them both server and client is plenty of work.

This is an attempt at a modern, cohesive API for email.

Your comparison between Switchboard and Inbox is solid. Switchboard is being used for tasks like sending "new email" push notifications to mobile clients, or uploading attachments to dropbox. I haven't used Inbox yet, but I'm excited to try it out.

It's great that Inbox is also built on top of IMAP. The new Gmail API is great, but an application which takes advantage of it is locked into using only Gmail. By building from the standard, Switchboard and Inbox are cross-provider.

I love it! Are there any plans for including the hypem time machine feature?

Do you not give any applications IMAP access to your email?

Email allows someone to send me data, as opposed to HTTP/S which targets servers. Adding structured data to emails could allow natural language communication to have a machine readable view of the communication. And there's probably a lot more uses.

> Erlang/Elixir certainly doesn't have the necessary breadth of libraries to support general-purpose tasks.

After doing quite a bit of work with Erlang lately, this sentence jumped out at me. Specifically, I think Erlang does have a breadth of libraries, but they're not easy to find. I've had to pluck lone source files out of larger projects, or depend on an obscure github fork since the original was unmaintained. epgsql was a great example of this, though no longer thanks to davidw's yeoman work [1]

Maybe not the right place to ask this, but would anyone be interested in something like the Clojure Toolbox [2] for Erlang? I've always found having that reference of libraries organized by task to be super handy when working with Clojure.

[1] http://journal.dedasys.com/2014/04/27/an-erlang-postgres-dri...

[2] http://www.clojure-toolbox.com/

You're correct that Lamson provides tools for processing emails, but it doesn't include a mechanism for feeding it emails from IMAP servers. Switchboard actually complements Lamson -- Switchboard could manage IMAP connections, collect incoming emails, and feed those emails to Lamson. You'd be able to use Lamson in front of Gmail/Yahoo/etc

I'm not super familiar with Apache James, but it appears to be a mail server with pluggable components. Switchboard fits in as a layer between any mail server that supports IMAP, and its version of pluggable components [processes connection over the interface].

Thanks, this really helps us see where the documentation needs to be improved :)

1. IMAP is powerful and ubiquitous, but it does put a lot of work on the client: implementing a parser, caching values, correctly handling unsolicited messages. Switchboard tries to carry some of this boilerplate weight.

2. Yes! We still have to work this into Switchboard, but conversations in the JMAP (http://jmap.io) spec give an idea of how it will be implemented.

The application uses IMAP UID/UIDVALIDITY values, typically along with IDLE, to identify new emails in a mailbox. These don't change when an email is read, so marking as read doesn't introduce any race conditions in this case.

For Switchboard's intended task of as-they-arrive email processing, speed is not a huge issue. That being said, there are plans for using more than one IMAP connection to parallelize some requests.

Switchboard is fairly different from context.io. Switchboard is open-source -- being able to keep in control of services accessing emails on your users' behalf is great. Also, Switchboard is intended for processing emails as they arrive using worker processes, as opposed to context.io which appears to be primarily a proxy.

I worked with Spatch to make Switchboard, and will be around to answer any questions.

Our motivation in building and continuing to build Switchboard is to make it easier for developers to process emails. Looking forward to more ideas!

Yup, IMAP is powerful, but it's gathered some baggage over the years.

Switchboard uses a simplified interface based on JMAP[1] for client's and workers, which it does proxy into IMAP commands. One of the conveniences of Switchboard is it manages the IMAP connections: restarting them as they fail and allowing concurrent access.

[1] http://jmap.io/

Complementing the thought on sentence structures: 5 word sentences could be extracted from existing texts. Tagging them would give you the set of possible sentence structures.

Hopefully there wouldn't be too much trouble with ambiguous word types, e.g. green can be either an adj or noun.

But, both of your driving factors, affected patients, and price to treat, are in turn driven by other factors such as competition, targeting symptoms, and the cost of research.

While perhaps not blockbuster, orphan drugs for rare diseases can turn quite a profit for pharmaceuticals.

http://www.forbes.com/sites/johnlamattina/2012/05/02/how-com...

http://online.wsj.com/article/SB1000142412788732392610457827...

This must have made a wonderful internal bug report in Apple.

Perhaps a profanity filter lurking where it didn't belong?