Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

The UNIX philosophy suggests we built a lot of simple programs that do one thing well and that we do them with text streams. That is, the standard input/output channels are sufficient means of messaging.

Console programs cannot only be piped together, they can also be directed to a file. In doing this, you can essentially queue up messages (text in files) for later processing. This seems to follow a similar model to message queues but without all the sophistication.

Richard P. Gabriel suggests that a key advantage of Unix was that it embodied a design philosophy he termed "worse is better", in which simplicity of both the interface and the implementation are more important than any other attributes of the system—including correctness, consistency, and completeness.

From my perspective, text streams provide about as simple a channel of communication as possible. This would seem to follow the worse-is-better philosophy. Couldn't we thus use console applications and files written to the file system as a poor man's message queue? And if so, has anyone successfully taken and preferred this approach? I am simply wondering how practical/feasible it is to substitute text stream processing for message queues.

share|improve this question
1  
Well, what about named pipes? I think that has the benefit of having one reading and one writing process while using files is prone to mutual exclusion problems. –  slhck Aug 27 '13 at 14:55
    
Do you mean something like command > foo and then watching as messages come in to the file foo with tail -f foo? –  terdon Aug 27 '13 at 15:03
    
I was thinking that the message would be intercepted from a file via some sort of polling process. –  Mario Aug 27 '13 at 16:02
    
Named pipes looks good too. That's something I hadn't encountered before. –  Mario Aug 27 '13 at 16:06
add comment

1 Answer

up vote 1 down vote accepted

Many mailservers use files on disk for their queue. Exim keeps each email in a file along with another file of metadata. The main benefit of this is crash-resistance: the queue survives a crash and reboot.

Files are usually going to be slower than using a message queueing system like 0MQ, and there are efficiency issues (how do you tell when a new message has entered the queue?), but for small applications or ones where you want a persistent queue it can work well.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.