I think I haven't clearly understood where to use Switchboard. In my normal mail stack (postfix, dovecot) where would Switchboard be placed?
Show HN: Switchboard – open-source email processing in Erlang
21–30 of 38 posts
Re: Show HN: Switchboard – open-source email processing in Erlang
#22Why is this based on IMAP? When I see "server-side email processing" I think SMTP.
If we were doing “server-side email processing” of emails as they were sent, SMTP would have fit in.
Re: Show HN: Switchboard – open-source email processing in Erlang
#23I think I haven't clearly understood where to use Switchboard. In my normal mail stack (postfix, dovecot) where would Switchboard be placed?
It would sit along side your Dovecot server. The Switchboard core subscribes to events in a folder (using IMAP IDLE) and issues change events to connected workers.
Re: Show HN: Switchboard – open-source email processing in Erlang
#24Re: Show HN: Switchboard – open-source email processing in Erlang
#25On a side note - its funny how things flow on HN sometimes - yesterday I played with PlanLeaf, and had the thought 'nice, but it'd be even nicer to just have the code to process emails properly', and now .. along comes a stack that gives me a way to do just that ..
Re: Show HN: Switchboard – open-source email processing in Erlang
#26Does anyone know how this compares to Lamson (which has been around for quite some time) ? [1] http://lamsonproject.org/
Re: Show HN: Switchboard – open-source email processing in Erlang
#27Does anyone know how this compares to Lamson (which has been around for quite some time) ? [1] http://lamsonproject.org/
Switchboard doesn't have any direct connection to SMTP. It monitors changes in your mail store using IMAP IDLE and issues events to workers which can then do basically whatever your heart desires.
(btw, we host our switchboard mailing lists on librelist.com which is a showcase for Lamson. cool project)
Re: Show HN: Switchboard – open-source email processing in Erlang
#28I 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!
Since I sent my first email in the 80's, I've wanted to build business-logic systems with mail-based interfaces - things like, have an address such as "calendar@mydomain.com" which can be cc'ed on emails which might contain future scheduling events, and have the calendar@ client automatically work out the details of reminding everyone of the date-target that was set .. Seems to me that Switchboard would be the ideal platform upon which to develop such services .. among other things too. See any gotcha's?
Its always amazed me that automated email is not used more and more for basic business processes - sure, we have mailing lists and autoresponders and all sorts of things like that, but the fact that most language/tech stacks don't really treat email as the human-maintained message queue, with first class priorities, seems a little lacking .. I guess Switchboard is an attempt to make up for that. Anyway, thanks again - I'll certainly be devoting some research time to this tool, and I hope I can build something useful on top of it ..
Re: Show HN: Switchboard – open-source email processing in Erlang
#29I 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…
Re: Show HN: Switchboard – open-source email processing in Erlang
#30Earlier quoted context omitted.
It would sit along side your Dovecot server. The Switchboard core subscribes to events in a folder (using IMAP IDLE) and issues change events to connected workers.
so is this like zeromq for mails?
We actually thought about using zeromq, but went with a simpler solution for now, i.e. using websockets.