Optional message handling

[Justin F. <vh...@us...>]

I've been thinking about adding the ability for modules to refuse 
processing a message, passing it to the next listener.  This way known 
messages could be extended by modules, instead of introducing the new ones.

This would be mostly applicable to protocol handlers, such as IRC, where 
a message carries whatever the client said, only parsing it to a more 
readable binary structure.  Take IRC for example.  If the standard 
protocol handler does not support a command, say, "WHOWILLBE", it just 
reports an error to the client.  To support such command, a new module 
must be written which handless all commands including "WHOWILLBE".  Or 
passes "common" messages to another handler of the same kind.

So, it's all about chaining the subscribers.  This is not the case when 
notifications can be used: if a protocol command is unhandled, an error 
must be reported, it must not just be ignored (which would happen if we 
used notifications to deliver protocol commands).

Adding such a function would be a matter of one function (say, 
para_msg_bounce()), which, when called, would forward the message to the 
next subscribed queue, leaving the sender blocked.  When the end of the 
queue is reached, a PEC_MSG_NO_RECIPIENT error would be reported.  There 
is one side effect: messages could be hijacked, modules could spy one 
over another.  I currently don't know whether it's good or bad.

Also, the whole chaining stuff is somewhat specific to protocol 
handlers, I believe, and I'm not sure if it's not too specific to be 
added as a base function.

Also, if there are different ways of implementing this, which I have 
somehow missed, I'd like to know about them.

This is a call for comments, yes.