Show HN: Switchboard – open-source email processing in Erlang
switchboard.spatch.co
Show HN: Switchboard – open-source email processing in Erlang
1–10 of 38 posts
Re: Show HN: Switchboard – open-source email processing in Erlang
#2Looks nice so far, worked with IMAP for a while, not fun... So is it on top of IMAP or ... ?
Re: Show HN: Switchboard – open-source email processing in Erlang
#3Looks nice so far, worked with IMAP for a while, not fun... So is it on top of IMAP or ... ?
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/
Re: Show HN: Switchboard – open-source email processing in Erlang
#4Looks nice so far, worked with IMAP for a while, not fun... So is it on top of IMAP or ... ?
It seems to be, as far as I understand.
If that's actually the case, how do you handle the case where someone read a new mail (and thus, mark it as read) before app processed it ?
Re: Show HN: Switchboard – open-source email processing in Erlang
#5I worked on an email application for a year that was on top of imap. It was slow as hell. How does switchboard get around that?
On another note, I think context.io provides a decent paid solution. How is this project different?
Re: Show HN: Switchboard – open-source email processing in Erlang
#6I did a project like this a few years ago and here are my takeaways:
1. Building on top of IMAP is very difficult. It's not a technology that is really designed for the mobile world of today (e.g. streaming, sockets for chat)
2. Threading is a bitch. The old folder tree layout is formidable.
----------------
That said, it's so cool to see something like this in the wild. As an engineer, I would've used this as a boilerplate for my project years ago, and it would've saved me literally six months of efforts.
Kudos to this. It's gods work.
Free startup idea: Use this to help larger businesses collaborate more efficiently (much like if Yammer and GTasks had a baby).
Re: Show HN: Switchboard – open-source email processing in Erlang
#7I 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!
Re: Show HN: Switchboard – open-source email processing in Erlang
#8I did a project like this a few years ago and here are my takeaways: 1. Building on top of IMAP is very difficult. It's not a technology that is really designed for the mobile world of today (e.g. streaming, sockets for chat) 2. Threading is a bitch. The old folder tree layout is formidable. ---------------- That said, it's so cool to see something like this in the wild. As an engineer, I would've used this as a boil…
It seems to me that this is the startup idea, built on top of this tech.
Re: Show HN: Switchboard – open-source email processing in Erlang
#9I worked on an email application for a year that was on top of imap. It was slow as hell. How does switchboard get around that? On another note, I think context.io provides a decent paid solution. How is this project different?
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.
Re: Show HN: Switchboard – open-source email processing in Erlang
#10I did a project like this a few years ago and here are my takeaways: 1. Building on top of IMAP is very difficult. It's not a technology that is really designed for the mobile world of today (e.g. streaming, sockets for chat) 2. Threading is a bitch. The old folder tree layout is formidable. ---------------- That said, it's so cool to see something like this in the wild. As an engineer, I would've used this as a boil…
It seems to me that this is the startup idea, built on top of this tech.
Seemed to me that it wasn't particularly meant for internal business comms. Just random comms.