Re: 'Private' messages in Exodus

Fred O'Leary wrote:
> I'd like to be able to deliver messages to Jabber clients and have a custom
> plugin control the UI appearance. I.e. I don't want message dialogs or
> headline alert dialogs. For example when an instrument sends a 'private
> message'to the jabber client, I want to present a custom dialog.

OK... So I was thinking about this problem and I think the solution is to create
multiple dispatch signals which represent different "chains" through the client.
When you register to catch packets coming in from the socket/server, you would
use the appropriate signal to catch those packets. (Right now, there is only a
single signal: /packet).

My initial thought is that there would be at least 4 signals:

/pre = catch stuff before anyone else (pre-processing)
/special = catch stuff based on pretty fine-grained xpath statements. This would
include things like all x:data messages, MUC invites, etc.. Used somewhat by the
core client, but also by plugins a lot to catch specialized packets (This is
where you would want to hook in, Fred).
/packet = Normal processing... used a lot by the core client.
/unhandled = No one else caught the packet. This would be for "last chance"
processing, like general message type="error" processing, etc.

The magic part is that the next signal would ONLY fire if the packet was not
caught by any of the listeners to the current signal. If a packet is caught, all
listeners to that signal still catch it, but ithe packet would never make it to
the next signal.

For example, a plugin would register for:
/special/message/x[@xmlns='http://pgmillard.com/jabber/foo.xsd']

If a message comes in that matches this xpath, then my plugin would get it
before the core client could does, so my plugin can pop-up a custom GUI. Since
the packet would never make it to the "/packet" signal, the normal GUI would
never pop up.

BTW, this would also simplify some special case logic that currently exists in
the client, and would make things a lot more modular.

This is all super easy to implement, my only concern at this stage is the
"coverage" of those 4 signals.. Are they enough to catch all possible
circumstances? Potential plugin authors, please speack up :)

pgm.