Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Thanks for high quality reply.

Likewise; thanks for engaging constructively as well.

> I traditionally have treated this as a state in a database.

Which is a super appropriate tool many (most) times! I've been using "MQ" in this context refers to the conceptual capability to externalize/distribute/persist work with a push/pop API. That can be provided by a database, a UNIX pipe, or a more traditional message broker--the reasons-to-adopt and costs/benefits are largely the same.

> I want to try the email idea sometime.

Email (and the print spool) are some of the oldest message-queue primitives on UNIX systems, I think? I'm not sure if POSIX/shmem MQs predate them or not, but they're all quite venerable proofs that the pattern has its uses. I'm sure you can (maybe others already have?) use SMTP and the mailq to manage application-internal queue communication. I'm not sure how low-overhead or performant it'll be given that it's highly optimized for one/very few consumers and delivery attempts >1 being attempted on a pretty large time scale compared to application traffic, but it'd be an interesting experiment to be sure!



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: